Re: [Veritas-vx] Usetype swap removed ?
# vxassist -g g3700 maxsize usetype=swap VxVM vxassist ERROR V-5-1-752 No volume can be created within the given constraints Same command with fsgen usetype works fine : # vxassist -g g3700 maxsize usetype=fsgen Maximum volume size: 2239895552 (1093699Mb) Should I conclude that the swap usetype has been removed starting from 4.0 ? I don't have a copy of 4.0. I'm unable to replicate that error on my Solaris/VxVM 4.1 machine (no problems creating multiple volumes with usetype=swapvol), and I see examples of usetype=swap used in some 5.0 documents. So it appears to be there in general. Not sure if 4.0 has a bug associated with it. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Vxdisk list showing LUNs on 2 paths
Hi Guys: I have a server running Sol 10 / VxVM 4.1 / vxdmp And where's the storage comfing from? Storage was presented , but vxdisk list shows the disks on 2 paths . I did a vxdisk rm and removed the second path but when I run vxdctl enable , it picks both the paths. Server was rebooted with --r but still same issue . Anyone has any idea why its happening and whats the fix ? This is output of vxdisk list EMC0_0 auto--error EMC0_0 auto:none --error EMC0_1 auto:none --online invalid EMC0_2 auto:none --error EMC0_2 auto--error [snip] Do you have the necessary ASLs for the storage installed? -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Reclaim volumes from failed backup.
On Wed, Oct 03, 2007 at 11:19:18PM +, A Darren Dunham wrote: I have a very large backup that failed. This one image spanned several volumes. When I look, I see the last volume it used got cleaned up by a bpexpdate -deassignempty, but the ones written to (and filled) earlier did not. Never mind, I was just impatient. I don't know what process goes out and finds them, but they all got reclaimed shortly after my post. *whew* -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Help ... vx volume is corrupted and doesn't accept fsck command
On Thu, Oct 04, 2007 at 06:07:24PM +1000, Rick Capaldo wrote: One of my VX volumes is unable to mount. When I try to mount the volume I get: # mount -F vxfs /dev/vx/dsk/dg-ovpidb/vol-ovpidb-data /mnt UX:vxfs mount: ERROR: V-3-21268: /dev/vx/dsk/dg-ovpidb/vol-ovpidb-data is corrupted. needs checking This is actually the filesystem that is upset, not the volume (not that that helps you very much). If I do a fsck on the volume I get: # fsck -o full -F vxfs /dev/vx/dsk/dg-ovpidb/vol-ovpidb-data UX:vxfs fsck: ERROR: V-3-20729: OLT extents conflict read of primary OLT failed UX:vxfs fsck: ERROR: V-3-20727: OLT extent 1 has bad magic read of OLT copy failed UX:vxfs fsck: ERROR: V-3-20718: no valid OLT, cannot continue file system check failure, aborting ... Is this error terminal or is there a way that I can recover the volume so that it can be mounted? If 'fsck' isn't helping, then it's well beyond my abilities. I would open up a support case. They can sometimes work magic. Do you have any history of why this filesystem might have been corrupted? Since the volume is okay but the FS is bad, could something have scribbled over the top of it? The state of the volume and plex is ACTIVE ENABLED Right. The volume is probably fine (otherwise you'd get read errors from fsck). -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] How to encapsulate a root disk already under Veritas VM (SF 5.0):? Weird problem
On Wed, Oct 10, 2007 at 09:23:29PM +0530, Arjun koneru wrote: if the slices 3 and 4 of your bootdisk are not used for anything - zero them out using format , run vxdctl enable and try the encap again. Probably not a bad idea. But remove the disk from the diskgroup first. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] How I tell VM to try to use plex labeled as IOFAIL? DISABLED FAILED on both plexes
On Tue, Nov 13, 2007 at 09:04:12AM -0500, Aleksandr Nepomnyashchiy wrote: SENA1_6 sliceddatadg_new1 datadg online SENA1_7 sliceddatadg_new2 datadg online So the disks are online... /[EMAIL PROTECTED],4000/SUNW,[EMAIL PROTECTED]/[EMAIL PROTECTED],0(ses47) offline Nov 12 05:58:15 ap4 unix: /[EMAIL PROTECTED],4000/SUNW,[EMAIL PROTECTED]/ses (ses-1) offline Nov 12 05:58:15 ap4 unix: /[EMAIL PROTECTED],4000/SUNW,[EMAIL PROTECTED]/[EMAIL PROTECTED],0(ses46) offline Nov 12 05:58:15 ap4 unix: /[EMAIL PROTECTED],4000/SUNW,[EMAIL PROTECTED]/ses (ses-1) offline Nov 12 05:58:15 ap4 unix: /[EMAIL PROTECTED],4000/SUNW,[EMAIL PROTECTED]/ssd (ssd-1) offline Nov 12 05:58:15 ap4 last message repeated 2 times Nov 12 05:58:16 ap4 unix: /[EMAIL PROTECTED],4000/SUNW,[EMAIL PROTECTED] (ifp0): Nov 12 05:58:16 ap4 LIP reset occured But you obviously had an underlying connectivity issue at one point. Did you figure out what caused this and resolve this issue? v DB_DATAnew1 -DISABLED ACTIVE 10485760 SELECT-fsgen pl DB_DATAnew1-01 DB_DATAnew1 DISABLED IOFAIL 10487876 CONCAT-RW sd datadg_new1-04 DB_DATAnew1-01 datadg_new1 67117876 10487876 0 SENA1_6 ENA pl DB_DATAnew1-02 DB_DATAnew1 DISABLED IOFAIL 10487876 CONCAT-RW sd datadg_new2-04 DB_DATAnew1-02 datadg_new2 67117876 10487876 0 SENA1_7 ENA Now that I've reread the config, your disks are all attached, so you can't reattach them. I think at this point you can start the volume just by running vxvol start with the 'force' option. Or you can examine the plexes independently (by attaching thme to their own volumes), make sure one looks good, then sync with that one. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] vxresize with volume of type gen
On Tue, Dec 11, 2007 at 12:02:04PM +0100, Michael Zimmer wrote: Has anybody some experience with shrinking a volume with vxresize -f -F vxfs -g DG vol size. Can I do this with gen type volume without loss of data? It shouldn't be a problem. But you can always use 'fsadm','vxassist' in place of 'vxresize'. Use fsadm to shrink the filesystem first, then use vxassist to shrink the volume. I think all 'fsgen' does here is give a hint that the filesystem should be flushed before shrinking the volume, so there shouldn't be a big problem with using 'vxresize'. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] vxdisk list shows disk in error status
On Wed, Jan 23, 2008 at 03:45:17PM -0500, Romeo Theriault wrote: I am using Veritas Volume Manager 4.1 on Solaris 9. Disk c4t2d0s2 shows this status: # vxdisk list | grep c4t2d0s2 c4t2d0s2 auto:sliced --error Is that a problem? Not a big deal but I would like to get rid of the error state and remove the drive from Veritas's knowledge so it shows up like the other local drives, which is: c4t1d0s2 auto:none --online invalid Use vxdiskunsetup on the disk if it is no longer in any VxVM disk group and has no valuable data on it. That will remove the VxVM partition setup on it. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] vxdisk list shows disk in error status
On Wed, Jan 23, 2008 at 05:56:15PM -0500, Romeo Theriault wrote: Thank you for pointing this out. Though when I run it I get this error. # vxdiskunsetup c4t2d0 VxVM vxdiskunsetup NOTICE V-5-2-3522 c4t2d0: Disk is not a volume manager disk So I guess veritas doesn't seem to think it knows anything about the disk in this case. I also tried repartitioning and labeling the drive then running vxdclt enable but it is still showing up as auto:sliced with a status of error. I'm leaning towards leaving it alone at this point as it doesn't seem to be causing any problems. It shouldn't cause any problems, but you can likely get rid of it by adding it back into VxVM and then unsetting it again. # /usr/lib/vxvm/bin/vxdisksetup -i c1t8d0 # vxdisk list | grep t8 c1t8d0s2 auto:cdsdisk--online # /usr/lib/vxvm/bin/vxdiskunsetup c1t8d0 # vxdisk list | grep t8 c1t8d0s2 auto:none --online invalid -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] replace encapsulated root disk
On Wed, Feb 20, 2008 at 08:09:26AM +, Neil Swallow wrote: Having lost an encapsulated root disk (called rootdisk) running vxvm 3.5 on solaris 2.6, and kept the server running on the mirror (normal vx initialized disk) I can't now use vxdiskadm to replace the disk. When I go to replace it, it insists that the public region is too small. Defaults have changed across versions. You now have to give vxdisksetup extra arguments to tell it to leave some space alone. Looking at the old vtoc, this is true. VM wants to initialize a disk that I want layed out as though it had been encapsulated. Since your mirror (then one you're running from) is already an initialized disk, why don't you want the other disk to be one as well? It should run just fine. I've tried things like `vxdisksetup -i disk old_layout` but again this tries to initialize to the standard 2 slice layout where the original had a public region of the entire disk with the private and original slices sat inside this in whatever magical manner VM manages to carry that out. Yes, but that should be the preferred way. Is having it initialize the disk like this causing problems? Is there anyway I can lay the disk out as I want and then just tell VM to trust me that it's initialized/encapsulated and let me go on and re-mirror or will the sync ignore the old slices anyway as it splats the data back on? Sync always ignores slices (which is why your mirror is already an initialized disk). The only thing that an encapsulated disk does is have subdisks/volumes created at the exact locations that the slices already exist. If there's no way forward I'm looking to have to remove the mirror totally, add the replacement disk as a new one and mirror back, losing the ability to boot from the underlying devices (unless I start looking at vxmksdpart which looks a bit daunting). When you mirror the root filesystem, it will create an underlying slice for you automatically. There has to be one on your existing mirror disk (which you're booted from) as well, correct? You can create slices for other filesystems if you want via 'vxmksdpart' as well (assuming you have free slice numbers). -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] command to see what drive booted a Sun/Solaris
On Thu, Feb 21, 2008 at 04:31:15PM -0800, Craig Simpson wrote: I know it exists but forget it. What is the/a command to see what drive booted a Sun/Solaris server running vxvm mirrored drives? The VxVM list page has a link to: http://www.eng.auburn.edu/pub/mail-lists/ssastuff/ It's #39. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] remove failed was:c1t1d0s2
On Thu, Feb 21, 2008 at 12:45:27PM -0800, Craig Simpson wrote: On one of my test servers (sandox play stations) I pulled my rootmirror to put a larger drive in for data. Normally you'd remove the disk from VxVM before you physically remove it. How can I chase out the reference to the failed disk (failed was:c1t1d0s2)? I have already removed the plex's attached to it, that made the mirrors to rootdisk. [EMAIL PROTECTED]:/#vxdisk -o alldgs list DEVICE TYPEDISK GROUPSTATUS c1t0d0s2 auto:sliced rootdisk rootdg online c1t1d0s2 auto:cdsdiskoradata_disk_01 oradata online -- rootmirror rootdg failed was:c1t1d0s2 Remove the disk from the diskgroup. vxdg -g rootdg rm rootmirror. If there are no objects on the disk, it should succeed. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] remove failed was:c1t1d0s2
On Fri, Feb 22, 2008 at 11:56:30AM -0500, Romeo Theriault wrote: In vxdiskadm use this option: 4 Remove a disk for replacement That's appropriate if you're changing out a platter but want to retain the configuration. He actually removed the disk from acting as a root mirror (and as I interpreted it, he no longer is going to have a mirrored root). -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Realigning sub-disks
On Fri, Feb 22, 2008 at 10:39:17AM -0600, Denton, Sam wrote: I'm putting together the list of commands that will be used, and I'm wondering if I can grow a subdisk that's at the head of a plex, as is the case with the second volume. I suspect that I'll need two new subdisks, one the same size as c6t0d70-02, and one to add to the end of the plex. Is this correct? I think so. But you can later move the data around so that the data is in the right order. If you have two subdisks with truly adjacent data, then you can combine them back into one (vxsd join). So you end up with the same behavior, but you can't do it in one step (at least not online with data present in the plex). -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] VFS snapshots as a way to undo changes?
On Fri, Feb 22, 2008 at 12:01:43PM -0500, Ray Arachelian wrote: I wonder if it's possible to use snapshots to undo changes to a file system without having to copy everything back? I'm not too familiar with what snapshots can do in VXFS, so that's why I'm asking... Snapshots are read-only. I think storage checkpoints would be more appropriate. Then you could perhaps run your DR test on the checkpoint. When you're done, toss the checkpoint and come back up on the regular (untouched) filesystem. I suppose I could hack something up with rsync, but that would probably be almost as time consuming as just copying the snap volume data back to the main volume. I'm not so sure. rsync should be pretty good about skipping portions of a file that are identical, so it might be quite useful. Also, rsync is really worst when you have lots and lots of files. In a DB test, you probably don't have all that many files. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] encapsulation requires a reboot - why?
On Sun, Mar 02, 2008 at 12:25:26PM -0600, Asim Zuberi wrote: The reason I am enquiring the details of the encapsulation process is because of capturing Solaris Zones under VxVM control. To make Solaris Zones part of VxVM every time a zone is created, making it impossible to reboot the physical system so often. So we're looking into options where a reboot of the physical can be avoided. I'm missing something here. Why would you need to encapsulate to create a zone? Are you trying to hand a VxVM volume to the zone for some reason (rather than export the filesystem with lofs)? I would normally expect to create a volume and install the zone onto it with no need to encapsulate anything. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] vxstat read write time question
On Wed, Mar 05, 2008 at 05:01:14PM -0800, Craig Simpson wrote: What are good Average Time(ms) for read write when running against a diskgroup? That depends on the layout and the performance of the underlying storage. It had better be faster talking to a high-end array than it is talking to some old 5400RPM 2GB disks in a Raid 5 config. [EMAIL PROTECTED]:/root/Perf#vxstat -ps -g oradatadg OPERATIONS BLOCKS AVG TIME(ms) TYP NAME READ WRITE READ WRITE READ WRITE pl redo1-01 303 9959611323244484 38.96.4 sd oradatadg03-01 303 9959611323244484 38.96.4 pl redo2-01 4 9960 42445005.05.8 sd oradatadg04-01 4 9960 42445005.05.8 pl stagevol-01 6560 9385448192288435 24.9 10.7 sd oradatadg01-01 6560 9385448192288435 24.9 10.7 sd oradatadg02-01 0 0 0 00.00.0 Pretty good write times, I assume this device has a write cache. Reads seem a bit high, but you don't have many redo reads, so it might just be contending with all the writes. Whether those are good or bad numbers depend on what you've purchased to produce them, and what your expectations are on the application. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] relayout question?
I would like to convert the following CONCAT volume to a STRIPED volume (striped across 8 columns). I am trying to use relayout option with the vxassist command to change the layout, but unable to fullfil the free blocks requirements for relayout to work successfully. Can someone please explain me on how to calculate the minimum free block requirements for the relayout process. I can't guarantee that it's all correct, but there's a technote on requirements from the Symantec site. http://seer.support.veritas.com/docs/248062.htm -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Veritas-vx Digest, Vol 24, Issue 10
On Thu, Apr 10, 2008 at 07:23:32PM +0530, Satishkumar Bhopale wrote: sd 87841000-01 vol01-01 87841000 0 70703104 0 c4t21d35 ENA Let's look at the output of the command : # vxdg -g mid01dg free DISK DEVICE TAG OFFSETLENGTHFLAGS 87841000 c4t21d35s2 c4t21d35 0 70703616 - Disk: it is the diskname given by Admin Device: The Physical Disk Device(s2 is the partition Which holds the entire disk info) Name Tag: The Physical Disk Name Offset: it is the starting point of the Data, written on the disk Length: It is the size of the data, written on the disk. Indicates from 0 to 70703616 are the used blocks. Ah, but this is the free command. It should be reporting free blocks and their extent, not used blocks. It shouldn't be showing anything that is allocated to a subdisk. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Increasing striped volume
On Fri, Apr 25, 2008 at 03:13:47AM +0530, Rajinder Bhalla wrote: Hi Gurus, I have a got a Solaris 8 server running VxVM 4.1 with VxFS. I have got a 2-column stripe volume of size 20 GB which needs increasing to 50GB. Can someone please guide me how can I increase a striped volume. I know how to do it on concat volumes but havent ever tried on striped voulmes on a production server. Pretty much the same thing. It's just if you don't have enough space on those disks, you'd need 2 others. You can't expand it onto a single device. (GUI, vxresize, vxassist are all possibilities) -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Encapsulation turns of logging on rootvol and swapvol?
On Wed, May 14, 2008 at 03:09:27PM -0500, Asim Zuberi wrote: Just recently we observed, during the encapsulation of the rootdrive process the OS native logging option for / and swap is getting turned off. Even though, during the OS install the logging option was explicitly set. Well, swap isn't a UFS filesystem, so logging doesn't mean anything there anyway. For quite some time there has been an interaction problem with logging UFS on a VxVM volume. Symantec has some technotes about it. The encapsulation script is disabling the logging feature intentionally. I don't know what the status is for your version of VxVM. http://seer.entsupport.symantec.com/docs/271404.htm In this example: OS = Solaris 10 update 4 VRTS pkgs = 5.0 with MP1 Question is, doesn't rootvol require logging? No. But the filesystem is unprotected against certain inconsistencies that can arise during a crash. /dev/vx/dsk/bootdg/swapvol - - swap- no nologging /dev/vx/dsk/bootdg/rootvol /dev/vx/rdsk/bootdg/rootvol / ufs 1 no nologging /dev/vx/dsk/bootdg/var /dev/vx/rdsk/bootdg/var /varufs 1 no logging The fact that the script attaches that mount option on the swap slice seems rather silly. But it doesn't seem to do any harm. -- Darren ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Moving Volumes to a new diskgroup
On Mon, May 19, 2008 at 02:09:59PM -0400, Chuck Sedlacko wrote: Thanks for your help! You were correct on both suggestions. Shrinking the disk group to a multiple of 16 (in sectors) allowed me to complete the implementation to move it to the new disk group. Yay! Glad it worked. Thanks for the report. I've never seen that limitation before. -- Darren ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Stripe on stripe
On Tue, Aug 12, 2008 at 10:54:43AM -0500, Barton Wold wrote: I recently changed jobs and have found that my new place uses Veritas striped volumes that go to a hardware array that is stripe/mirror'd. There are a lot of smart people here who have done benchmark testing to confirm that this is faster (I haven't seen those results). This doesn't make sense to me. Wouldn't it be slower? Not necessarily. I would think that you would be trying to write to different parts of the same drive at once?!? Perhaps, but even if true, you can't say that that specific effect outweighs others without testing. On some systems, the benefit of scheduling multiple LUNs for I/O on the host (sw striping) dramatically improves IO, even though the HW striping may be more efficient. Array level caches may negate any drawbacks of writing to a LUN in different locations. Also, it depends on the specific array and layout. If there's a large number of physical disks, then the stripe/stripe may not be doing double writes to any cylinders. Only some layouts would have that particular problem. -- Darren ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Disk Group import failed: Disk group exists and is imported
On Thu, Aug 14, 2008 at 02:14:16PM -0400, Romeo Theriault wrote: /etc/vx/diag.d/vxprivutil -D set /dev/rdsk/c2t500A098186E7C997d83s3 dgid=newid_number /etc/vx/diag.d/vxprivutil -D set /dev/rdsk/c2t500A098186E7C997d83s3 diskid=newid_number I'm not certain that that is sufficient. It could work, but I do not know that it covers all the bits that have to be changed. See also alternatives such as: http://mailman.eng.auburn.edu/pipermail/veritas-vx/2003-March/005632.html -- Darren ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] How to split a multi-plex volume?
On Wed, Dec 10, 2008 at 10:51:11AM -0800, Hazel, Geoff wrote: I have a server I inherited with /export/home at 7GB, with 1.5GB free. Now, it shows up in vxprint like this: v home -ENABLED ACTIVE 14363112 SELECT- fsgen pl home-01 home ENABLED ACTIVE 14366888 CONCAT- RW sd rootdisk-04 home-01 rootdisk 12595175 2101552 0 c0t0d0 ENA sd rootdisk-07 home-01 rootdisk 23098223 12265336 2101552 c0t0d0 ENA pl home-02 home ENABLED ACTIVE 14366888 CONCAT- RW sd rootdisk-m-03 home-02 rootdisk-m 6299944 2101552 0 c0t1d0 ENA sd rootdisk-m-08 home-02 rootdisk-m 23098224 12265336 2101552 c0t1d0 ENA It appears to me that when they built this box, the VX filesystems were just carved out of the root slice, and not off their own slices. root slice? I doubt it. There may have been some free space that could be used, but most root disks begin life as encapsulations, and the root slice would have been entirely consumed by the root filesystem. VxVM doesn't create slices by default for new volumes. What I'd like to do is to resize /export/home so that the 1gb subdisk becomes it's own volume. Is that do-able? Not explicitly mentioned, but is /export/home UFS (as expected)? If so, not online. You can't shrink UFS to only consume one of the subdisks. You can have VxVM move anything around, but you can't shrink the space for a UFS filesystem without doing a dump;newfs;restore step. -- Darren ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] How to remove subdisk from concat volume and preserve data
On Wed, Mar 25, 2009 at 10:47:33AM +0800, ssloh wrote: Hi folks, I would like to take out one disk from a concat volume with 3 subdisks and want to preserve the data, vxprint as following. v exp -ENABLED ACTIVE 87166976 SELECT- fsgen pl exp-01 exp ENABLED ACTIVE 87171072 CONCAT-RW sd t3b_v1_disk01-01 exp-01 t3b_v1_disk01 325828608 31457280 0 c1t2d1 ENA sd t3b_v1_disk02-01 exp-01 t3b_v1_disk02 146817024 41951232 31457280 c1t2d2 ENA sd t3b_v1_disk03-01 exp-01 t3b_v1_disk03 288092160 10481664 73408512 c1t2d1 ENA How to safely remove t3b_v1_disk03-01 ? This mount point is about 43GB, and currently only used 36GB, that is why I want to free up the last subdisk which is about 5GB and wondering will just remove it will cause data losses ? So you just calculate the size of the volume without that subdisk. Manual way would then be to reduce the size of the filesystem to less than that, then reduce the volume to that size as well, then remove the subdisk. If you use vxassist the reduce the size of the volume sufficiently, I think it'll remove the subdisk automatically. How to check whether any data written to disk03 ? Find out what's on the volume. Is it a filesystem? Is the filesystem the size of the volume? If so, then there's stuff written there. You have to reduce the filesystem first. -- Darren ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Help: remove disk from a diskgroup and give back to SAN
On Wed, Mar 25, 2009 at 08:56:49AM -0700, Mike Li wrote: What will be involved to remove c4t2d14s2 from the appldba diskgroup and vm to give back to EMC SAN? Backup DB to tape. stop DB. Unmount filesystems for vol03, vol07,vol08 vxassist -g appldba move vol03 !c4t2d14 vxassist -g appldba move vol07 !c4t2d14 vxassist -g appldba move vol08 !c4t2d14 vxdg -g appldba rmdisk vxdisk rm c4t2d14 appldba02 mount vol03,vol07,vol08 start DB Please provide sanity check. Thank you in advance Always want to test this out, but your steps appear correct to me. You don't need to stop the DB if you don't want to. All the vx commands will work with the data online. In fact, you don't show any unmounts, so you don't need any remounts. If you don't care where the data is moved, you should also be able to use 'vxevac' to have it evacuate a particular disk instead of the individual vxassist bits. Test early, test often, have a backup. -- Darren ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] root disk mirroring
On Mon, Apr 20, 2009 at 11:39:02AM -0700, Victor Engle -X (viengle - Insight Global at Cisco) wrote: Can someone direct me to a document with a good explanation of root disk mirroring and recovery with veritas vxvm 4.1 for Solaris? I have an encapsulated root disk with a mirror. I think I have a good understanding of the encapsulated disk and how to manually unencapsulate it because all the partitions are still intact. My concern is with the mirror. It's partitions are not the same as the root disk so if the root disk fails I'm not sure how it's possible to get back to having an encapsulated root disk. The reason I think I need an encapsulated root disk is that I can disable veritas and still boot from the encapsulated disk assuming I know how to unencapsulate it. Only difference is whether or not you have slices mapped to the different filesystems (volumes) on the mirror. At least root will already be mapped (can't boot without that being there). If there are other filesystems that are present but aren't mapped, you can create the slices with 'vxmksdpart'. If you've done that (or you don't have any filesystems other than root), then you're done. -- Darren ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] vxresize - but df(1) doesn't see new space ... ?
On Wed, May 13, 2009 at 11:42:43AM +0800, Wilkinson, Alex wrote: Hi all, I have a LUN that I need to expand via vxresize vxresize expands volumes and filesystems, not LUNs. Do you have a volume that is on a LUN that you already expanded? #df -h . FilesystemSize Used Avail Use% Mounted on /dev/vx/dsk/RDL_DG/VOL01 17T 8.7G 16T 1% /export I found the exact free space available via: #vxdg -g RDL_DG free And then successfully did a resize via: #/etc/vx/bin/vxresize -g RDL_DG -F vxfs VOL01 +12502704 All looked good (from vxresize's prespective). However, parted(1) can see the expanded space but the partition table will not allow me change its label: #parted /dev/sda GNU Parted 1.8.1 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p What is the relationship between /dev/sda and VOL01? Maybe you can show the output of vxprint -ht VOL01? I'm beginning to think that VOL01 is built on top of /dev/sda and you're trying to get VxVM to see the enlarged LUN? Model: DGC RAID 5 (scsi) Disk /dev/sda: 23.6TB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End SizeFile system Name Flags 1 131kB 33.8MB 33.7MB 2 33.8MB 17.7TB 17.7TB (parted) resize 2 17.7tb 23.6tb Error: Could not detect file system (parted) As you can see parted(1) does detect that /dev/sda is 23.6TB. df(1) does not see the new expanded 23.6TB but rather the old 17.7TB. Can anyone suggest why a vxresize would work perfectly fine yet tools such as df(1) cannot see the new space on the expanded LUN ? I think neither the volume nor the filesystem has been expanded because VxVM doesn't notice when LUNs change size. What version of VxVM do you have? -- Darren ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] ZFS to VxFS
On Wed, Jan 27, 2010 at 11:34:46PM +0200, Asiye Yigit wrote: Hello All; Is there any way to convert ZFS to VxFS? Not in-place. You need to pick it up and move it. UFS and VxFS have a lot of differences, but compared to ZFS they're practically identical twins. Writing a converter would be a huge amount of work. -- Darren ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] ZFS to VxFS
On Wed, Feb 03, 2010 at 05:45:09PM -0500, Hudes, Dana wrote: Future release of whose? I can't see Veritas/symantec putting effort into migrating away from vxfs+vxvm. Now, I could see Larry Ellison putting money into anything to take business away from any and every other company so perhaps the zfs wg would do something like that...or the community. I won't go out on a limb and say it's impossible, but the on-disk structure of ZFS is so different from UFS/VxFS or VxVM that I can't see it working in the general case without a *huge* (read expensive) effort. -- Darren ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Migrating volumes on windows servers [SEC=UNCLASSIFIED]
On Tue, Mar 16, 2010 at 03:53:40PM +1030, Robinson, Greg wrote: I mirrored the data in the normal way, broke the mirror, removed the disks from the disk group (and this is where I think windows vxvm got the better of me), and tried to import the disks and create a new disk group out of them and mount my volume. That's the complex way. Can't you select your mirror and have it split into a separate disk group? That group can then be deported and imported on the other server. My question is: how can I migrate the volume without deporting the disk group from one server and importing it from another. Split the mirror into independent volumes that are part of a new diskgroup, then deport that group. -- Darren ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Mirroring issue, while using multiple disks coming from different location
On Tue, Oct 12, 2010 at 03:58:47PM +0530, Mohd Aslam wrote: Is there some way I can define that while mirroring, plex data01-02 used 33GB space from disk02 and rest 50GB space from disk04. Instead of: # vxplex -g datadg -o rm dis data01-02 # vxresize -F vxfs -x -g datadg data01 +50g disk03 # vxassist -g datadg -b mirror data01 disk02 disk04 -- My problem is with this command. I would have suggested: vxresize -F Vxfs -x -g datadg data01 +50g disk03 disk04 Since the volume is a mirror at that point, it will extend onto the two new disks in a mirrored fashion. Given where you are now, I don't know of a way for 'vxassist' or 'vxresize' to mirror in the way you want. You could either remove the extra size, go back to the single disk, remirror on disk02 and then extend. Or you could set up a new plex on the new disks and then attach that to the volume. Maybe something like: vxassist -g datadg tempvol 33g disk03 vxassist -g datadg growby tempvol 50g disk04 # one plex on tempvol vxplex -f -g datadg dis plex You can then destroy the temp volume and attach the plex to the original volume. I don't like doing it this way because getting the sizes to match up exactly is difficult. -- Darren ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] vxdisk init a single disk slice ?
On Thu, Apr 28, 2011 at 10:39:07AM -0400, William Havey wrote: I'm curious as to the purpose of putting a slice in a disk group. Why do it? I know it was a work-around for rootdg requirements. But that's long gone. *production* purpose? Don't know. But I used it all the time for testing multi-cylinder setups on systems that didn't really have a lot of physical disks. You could create lots of disks and show raid setups and failures, even if you only have one or two disks on the test box. -- Darren ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] RAID-5 LOGGING
On Sat, May 07, 2011 at 07:07:26PM +0300, Asiye Yigit wrote: Hello all; ?t is recommended to add raid-5 log device to the volume to recover the correct data in any case including system crash. However, I am trying to understand how the data and parity changes are logged here? Do you know the structure of this area? Not the specifics. I believe it is basically an intent log for the R5 volume. Data and parity itself couldn't write here, if it is like that those area should be big enough. Correct. It is just temporary. Once all writes are committed, then the data is not needed. So the log area can be quite small. As far as i know, it is small area. What kind of information for each data and parity changes is holdin here to re-paly the log? Presumably it is the full set of changes that will be made to the parity stripe. I suppose it could be just the subset of changes on a less-than-full-stripe write as well, but that gets into the nitty-gritty details which I don't know about. What level of information are you hoping for? -- Darren ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
