Extend after mirror?

[Michael D. Zorn]

Our brand-new HP rp3410 has 4 73GB disks. So far, everything is on the first one, taking up about 15GB.

It seems reasonable to mirror the LVs (we have the usual lvol1..8). /home is one of them, and is only 32MB - so it's an obvious candidate for extending.

We're a development environment, so the users have their data space in /home/userN/ ... and need a lot of it.

The question is, if I mirror all the lvols in vg00 to the second physical disk, what happens when I lvextend /home onto the 3rd disk? Or should I not lvextend it with a -m?

[Pete Randall · Accepted solution]

When you extend /home, it's mirror volume will need to have sufficient space to be extended also. As long as both disks have enough space, there is no problem.


Pete

[A. Clay Stephenson]

You can specify the PV when an lvextend is done. If you simply make certain that a strict allocation policy (the default) is in place when the LVOL is created, you will ensure that mirrors reside on separate LVOL's even in the case where an LVOL might occupy more than 2 PV's not counting the mirror copy.

I would rethink my disk layout approach. In your case, /home is much more like applications data. I would move /home out of /vg00 and use 2 disks for vg00 - the OS only and use the remaining two disks for vg01 where /home will reside. This will make OS upgrades and patches much easier and cleaner. Of course, I know you are going to ignore this advice because the thought of all of that unused space in vg00 will drive you nuts but it is the wise approach.

[James R. Ferguson]

Hi Michael:

You can mirror every logical volume current in vg00 to a second physical disk and *then* extend '/home'. By default, physical extents will be allocated from both physical disks in equal numbers because by default, 'strict' allocation has been specified for the logical volume during 'lvcreate'.

I presume that your total '/home' filesystem size isn't going to exceed ~ (73-15 = 60+ GB). If that *is* the case, I would 'lvremove' the current '/home' and build it as a logical volume on *vg01* and mirror *that*. This will make mirrored life and the later extension of other logical volumes in vg00 much cleaner and easier.

Regards!

...JRF...

[Michael D. Zorn]

Clay is right (about all that unused space) - that's more free space than we had in our whole last K200 (17GB). But disks are cheap. . . . .

Both Clay and JRF's advice about moving /home to another vg makes sense. It's where the users romp - everywhere else is pretty much system land. I'll do that.

It looks like the original concept for lvols came about when disks were small and file systems were larger than a physical disk. Nowadays, disks are huge (though apps keep getting bigger and using more data). I doubt we'll ever need to make a FS larger than one of our 73GB disks. Even our current database files don't go over 600MB apiece.

[Nguyen Anh Tien]

Hi Michael
You have 4 internal disks. I would like to recommend you that you should move home to onother VG.
For mirror and extend:
I hope mirror lv is now in strict mode( each PE is copy to both PV) if that the VG must have at least 02 PV. When you issue lvextend the PEs will occupies on both PV

[MarkSyder]

I have the utmost respect for the three Olympians who have replied to you and hope none of them will be offended if I offer an alternative solution.

If you leave your job, the sys admin who takes over from you will probably expect to find /home in vg00. I would leave /home alone and set up a logical volume on vg01 for the user data. You could call this lv (for example) /home/users. To the users it would appear that their accounts were under /home. To the sys admin who takes over from you vg00 would be set up the way he (or she) will expect it to be.

Mark Syder (like the drink but spelt different)

[A. Clay Stephenson]

Actually, /home being in vg00 or not is hardly a big deal from the standpoint of administering a system. First, it's dumb to make any assumptions about the location of any filesystem other than /, /stand, and primary swap (okay the last one is not a filesystem) which must be on the boot disk and in the boot VG; all the others are up for grabs. So even on systems I administer myself, I also do a bdf before doing anything because aliens, elves, or orcs may
have come in and moved things in my absence. My only real rule for vg00 is that it is used for OS stuff exclusively.

In the case of /home, it's especially unwise to make any assumptions because a very common practice is to automount /home using NIS(+) maps so that regardless of where a user logs in, his home directory (which might actually reside on a machine in a galaxy far, far away) remains the same and is still "/home/thisuser" no matter where he is.

In this particular case, moving /home to another VG makes perfect sense because it involves the fewest changes to existing scripts and applications.

[Michael D. Zorn]

Mark has a good point - I always see the "canonical list of UNIX directories", but, like most standards, there are many of them. A lot seem to like to put user's files in /usr/home. But in the end, I think that having a big /home on another disk outweighs the standards-conforming way of leaving it on vg00. (Besides, I'll be here until at least HP-UX 45.33....)

I lean toward Clay's point about using vg00 for OS stuff exclusively. (Luckily, we're not a global-networked system, so we won't be doing any remote user mounts through an ansible (Le Guin, Orson Scott Card, &c ...)