SUMMARY: Increasing filesystem size by enlarging Vdisk (trucluster 5.1b-3/eva5000)
"Garsha, Adam" <[email protected]>
| Newsgroups | gmane.os.tru64.managers |
|---|---|
| Message-ID | <[email protected]> |
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: '[email protected]' 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 [email protected]