RE: ext3 efficiency, larger vs smaller file system, lots of inodes...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Ric Wheeler [mailto:rwheeler@xxxxxxxxxx]
> Sent: Tuesday, May 19, 2009 9:54 AM
> To: Joe Armstrong
> Cc: ext3-users@xxxxxxxxxx
> Subject: Re: ext3 efficiency, larger vs smaller file system, lots of
> inodes...
> 
> On 05/19/2009 12:28 PM, Joe Armstrong wrote:
> >
> > -----Original Message-----
> > From: Eric Sandeen [mailto:sandeen@xxxxxxxxxx]
> > Sent: Tuesday, May 19, 2009 9:21 AM
> > To: Joe Armstrong
> > Cc: ext3-users@xxxxxxxxxx
> > Subject: Re: ext3 efficiency, larger vs smaller file system, lots of
> inodes...
> >
> > Joe Armstrong wrote:
> >> (... to Nabble Ext3:Users - reposted by me after I joined the
> >> ext3-users mailing list - sorry for the dup...)
> >>
> >> A bit of a rambling subject there but I am trying to figure out if
> it
> >> is more efficient at runtime to have few very large file systems (8
> >> TB) vs a larger number of smaller file systems.  The file systems
> >> will hold many small files.
> >>
> >> My preference is to have a larger number of smaller file systems for
> >> faster recovery and less impact if a problem does occur, but I was
> >> wondering if anybody had information from a runtime performance
> >> perspective  - is there a difference between few large and many
> small
> >> file systems ?  Is memory consumption higher for the inode tables if
> >> there are more small ones vs one really large one ?
> >
> > It's the vfs that caches dentries&  inodes; whether they come from
> > multiple filesystems or one should not change matters significantly.
> >
> > The other downside to multiple smaller filesystems is space
> management,
> > when you wind up with half of them full and half of them empty, it
> may
> > be hard to rearrange.
> >
> > But the extra granularity for better availability and fsck/recovery
> time
> > may be well worth it.  It probably depends on what your application
> is
> > doing and how it can manage the space.  You might want to test
> filling
> > an 8T filesystem and see for yourself how long fsck will take...
> it'll
> > be a while.  Perhaps a very long while.  :)
> >
> >> Also, does anybody have a reasonable formula for calculating memory
> >> requirements of a given file system ?
> >
> > Probably the largest memory footprint will be the cached dentries&
> > inodes, though this is a "soft" requirement since it's mostly just
> cached.
> >
> > Each journal probably has a bit of memory requirement overhead, but I
> > doubt it'll be a significant factor in your decision unless every
> byte
> > is at a premium...
> >
> > -Eric
> >
> 
> How you do this also depends on the type of storage you use. If you
> have
> multiple file systems on one physical disk (say 2 1TB partitions on a
> 2TB S-ATA
> disk), you need to be careful not to bash on both file systems at once
> since you
> will thrash the disk heads.
> 
> In general, it is less of an issue with arrays, but still can have a
> performance
> impact.
> 
> Ric

Just for completeness, we will be using Striped LUN's (RAID-6 underneath), so I hope that the striping will distribute the IO's while the RAID-6 device will provide the HA/recovery capabilities.

Joe

_______________________________________________
Ext3-users mailing list
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users

[Index of Archives]         [Linux RAID]     [Kernel Development]     [Red Hat Install]     [Video 4 Linux]     [Postgresql]     [Fedora]     [Gimp]     [Yosemite News]

  Powered by Linux