Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!mit-eddie!wuarchive!decwrl!sgi!daveh@xtenk.asd.sgi.com From: daveh@xtenk.asd.sgi.com (David A Higgen) Newsgroups: comp.sys.sgi Subject: Re: Logical Volumes Message-ID: <72895@sgi.sgi.com> Date: 22 Oct 90 21:49:19 GMT References: <1990Oct22.171615.17166@cid.aes.doe.CA> Sender: guest@sgi.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 38 In article <1990Oct22.171615.17166@cid.aes.doe.CA>, aspgasd@cidsv01.cid.aes.doe.CA (Alain St-Denis) writes: > Is there a manual that explains all there is to know about logical > volumes? I already read the System Administrator's Guide. Suffering from a touch of multiple-post-itas, aren't we Alain? As I said in my last follow-up, I will try to answer specific questions. > I would like to know how the stripping is implemented and also how the > file space is allocated on a logical volume extended with growfs. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ No, no: this seems to be a widespread confusion. Growfs extends the *filesystem*, not the logical volume. A logical volume is extended by adding more devices to its specification in /etc/lvtab and rerunning mklv; you would do this *before* using growfs. I think there is some confusion because many people have heard the terms "striped files" or "striped filesystems". There are basically two ways you can do volume management & software striping. 1) You can modify the filesystem to have knowledge of the physical devices on which it resides, and add management policies to the filesystem itself to allow it to determine which physical disk a given file block is on, OR 2) You can build an intermediate layer, below the filesystem but above the actual disk drivers, which makes multiple real disk devices look to higher layers like a single device. We have used the latter approach: it is more modular and allows volumes to be constructed from any type of physical disk without modifications to the filesystem code. Our logical volumes are *devices*, the filesystem knows nothing about them. Dave Higgen (daveh@xtenk.asd.sgi.com)