Ext3 resizing and performance

[Gabriel Dragffy]

On Sun, 2006-12-10 at 23:08 +0100, Felipe Alfaro Solana wrote:
> On 12/10/06, Gabriel Dragffy <dragffy at yandex.ru> wrote:
> > Now I am in the Ext3 territory I do have a couple of things that I'd
> > like to clear up.
> >
> > Firstly I am unsure about the -T flag with news, largefile, largefile2
> > being options, which should I choose for best performance on / ?
> 
> This options control different aspects of the filesystem, like the
> total number of i-nodes of the filesystem. "news" usage is intended
> for a filesystem wil lots of small files (one i-node per 4KB so, for
> 4GB volume, you'll get 1M i-nodes). "largefile" is intended for
> filesystems with less and larger files than "news"  (one i-node per
> 1MB, so for a 4GB volume you will get 4096 i-nodes) . "largefile4" is
> intended for filesystems with few and very lage files (one i-node per
> 4MB, so for a 4GB volume you will get 1024 i-nodes).
> 
> The "-T" flag thus provides simple ways of controlling the number of
> i-nodes of the filesystem. For more fine-grained contro, you can use
> -N (numer of i-nodes) or -i (ratio of bytes per i-node).
> 
> > More importantly is how do you grow a logical volume ONLINE, without
> > first unmounting it when it is using Ext3?
> 
> You can use ext2online. However, ext2online has some limitations that
> resize2fs don't. For most of the typical use, ext2online will do fine,
> however.
> 
> > What does the "commit" function actually do? I have changed it from 5
> > seconds to 600 on my laptop - will that affect something adversely?
> 
> If my memory serves me well, it dictates the amount of time pdflush
> uses to look through the list of dirty blocks in order to write them
> back to disk. The longest the interval, the longest it will time for
> pdflush to write dirty buffers to disk, increasing the disk of data
> loss due to power outages and making the disk idle for longer time.
> 
> > I recently changed all my LVs from ReiserFS to Ext3 formats. I can't
> > believe the difference - about 20% increase in performance. GIMP now
> > starts in 5 seconds instead of 7 after the computer being freshly
> > rebooted. On the whole the computer seems to do a whole lot less
> > scratching when firing up applications. I can't say that ReiserFS was
> > fragmented, I had a standard desktop install and it was freshly
> > installed just 3 weeks ago.
> >
> > Before changing to Ext3 I gave JFS a whirl and found it to be sllooww.
> > Copying a large file took 6 mins as opposed to 4 on Reiser. And just
> > starting the computer or applications would result in more-than-required
> > HDD thrashing - obviously not a good filesystem for the computer and
> > quite perhaps easily fragmented.
> 
> I find XFS to be extremely fast, but I have suffered some problems in
> the past and I wouldn't recommend it for critical environments.

Thank you kindly for such a detailed response. I do understand what you
are saying but have a little difficulty applying to real world
scenarios....
Am I right in thinking that -T news is best for a root partition? That
-T largefile is best for a drive full of mp3/oggs and -T largefile4 for
a drive of movies?
Having changed the commit from 5 to 600 am I risking losing my work or
my data integrity - what's the reasonable maximum for this figure?

I am impressed with ext3 although it doesn't appear to be the best
choice in all situations for my desktop use it seems best. Only thing is
that it doesn't make good use of the space on my HDD, once you take into
account the block slack, the journal size (128mb defaults (on my drive)
whereas reiser was 8mb and the huge chunk reserved for super user which
I did reduce from 5% to just 2%. Still when usable capacity is cut by
several gigabytes before even using it I can't help but feel hard done
by. Especially since in the first place HDs are advertised as 100GB but
really are only 95GB or whatever.

Rant over!!