[svlug] Desktop usage of Linux LVM.

Mike Castle dalgoda at ix.netcom.com
Sun Oct 26 18:17:44 PST 2003


On Sun, Oct 26, 2003 at 05:30:23PM -0800, Scott Hess wrote:
> Hmm, interesting.  This is an issue I was concerned about.  Do the
> filesystem extender/contractor programs modify inode counts, or just
> filesystem size?  Currently, I'm forced to re-visit the inode count on

Well, it probably depends.  For ext2/3, it keeps the bytes/inode constant,
so as you increase the file size, you increase the number of inodes.
Couldn't speak for any other file system.

> every major hardware upgrade, but in an LVM world, I'll be stuck with it
> (unless I want to rebuild the filesystem, of course).  I usually leave
> myself _plenty_ of extra inodes, but try to trim them down to keep fsck
> times reasonable (4k/inode on 100Gig is FAR TOO MANY INODES for my needs).

Yeah.  I generally create a file system, figure out how many bytes/inode
are actually in use, create another file system with those specs and copy
stuff over to that one for one last time.

> Hmm.  By "defrag the LVs", you mean defrag the filesystem on the LV, not
> the LV itself, right?  I would assume that doesn't matter _much_, so long
> as you are careful to always expand the LV before the filesystem gets too
> full (rather than after!).

No.  I never defrag file systems.  So I did mean defrag the LV itself.  For
the file systems that actually get near full and have to resize, the usage
characteristics are such that nearly all the files get deleted and
recreated at some fairly decent interval.  If they're accessed at all, they
are deleted and recreated.

For defragging LVs, it's usually a matter of making sure they're contiguous
on a drive.  Biggest reason for this is for file systems that get parallel
use are on different media.

mrc

-- 
     Mike Castle      dalgoda at ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc




More information about the svlug mailing list