My Gold Support TAM followed up with the support person that had created
the instructions for the EVA SAN level disk resize procedure (that uses
manual disklabel edits):
Here is what the gentleman that tested this said, he is the same
individual that wrote the original procedures.
I was able to successfully perform the following in the ALF lab:
Operating System: Tru64 V5.1B PK4
# disklabel -r dsk153 > dsk153.backup
extend Vdisk at eva from 2GB to 10GB
# disklabel -rw dsk153
# mount -u -o extend /test_it
Notice you do not have to put in the partition letter or tell
disklabel the type of storage, that was a version 4.0x thing.
This worked just fine, the file system was mounted, no data was lost. I
unmounted and then remounted the file system and all was still fine. The
only point I want to make is that just because it worked in our lab,
this does not mean the company will bless this. I do not see why they
would not though. One last thought, I did not have any i/o going to the
disk when I did this, if Oracle or some other database or application is
writing to the disks the customer wants to expand, I would suggest
bringing down the database or application, just to be safe. Hope this
helps.
~~~~~~~~~~~~~~~~~~~~~
Here was my response (I haven't heard back; anyway, I have used
'disklabel -rw' now a number of times on live test systems with out any
issue):
TAM, Thanks much.
What would it take to get this "blessed" for live applications? I
already know that it works. I also know that folks in the field do this
as an operational technique and they have for some time. Would the
gentleman be able to get this "approved"? if there is such a thing.
Can you ask the gentleman why (or whether) he thinks this method is
riskier then the hand-edit disklabel method that he had documented? If
he does think that it is riskier, why? If he does not, why would this
method require an application shut-down vs. the hand-edit method.
Application shutdown is unacceptable... that is the whole point of
chasing the online resize method in the first place.
How much testing did the hand-edit method get prior to dispersal of the
document? Can this method go through the same process/path, so that the
support folks know that it is an "approved" technique.
"Approval" would benefit any enterprise that uses Tru64 unix and EVA
storage.
~~~~~~~~~~~~~~~~~~~~~
-----Original Message-----
From: Garsha, Adam
Sent: Thursday, September 15, 2005 5:27 PM
To: 'tru64-unix-managers_at_ornl.gov'
Subject: Increasing filesystem size by enlarging Vdisk (trucluster
5.1b-3/eva5000)
I have the following:
a.) database domain "foo" with a single fileset "bar".
b.) the filesystem is active
c.) the domain has a single whole disk under the hood (e.g. dsk100c)
c.) I want to increase the Domain size, but I want to only have one
drive per domain
d.) An EVA5000 disk array is presenting the LUN
I'd like to confirm that I can do the following on a 5.1-3 trucluster,
while keeping the filesystem active and available:
0.) backup the relevant domains (of course); e.g. mature snapclone
1.) Increase relevant presented Vdisk size within my EVA5000 using
commandview
2.) disklabel -r dsk100c > dsk100c.backup
3.) disklabel -rw dsk100c HSV110
4.) mount -u -o extend /foo/bar
I've recieved documentation from HP support that states instead of #3. I
should manually edit a disklabel protofile and then activate the new
disklabel. I am having a hard time getting anyone to commit to whether
using the -rw option will work. The ITRC forums suggest that it will.
Anyone able to say with confidence:
a.) that will not work! you will loose all data on the domain!
or
b.) that will work and is less error prone then manually editing the
disklabel
Adam Garsha
Systems Engineer
Marquette University IT Services
adam.garsha_at_marquette.edu
Received on Thu Nov 10 2005 - 20:06:18 NZDT