Re: abysmal performance

[Chris Mason <chris.mason@oracle.com>]

Excerpts from Bernhard Schmidt's message of 2011-05-03 07:43:04 -0400:
> Hi,
> 
> > Using compression is not a problem, but in order to reduce the maximum
> > amount of ram we need to uncompress an extent, we enforce a max size on
> > the extent.  So you'll tend to have more extents, but they should be
> > close together on disk.
> > 
> > Could you please do a filefrag -v on the file?  Lets see how bad it
> > really is.
> 
> 
> root@schleppi:~# filefrag -v
> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.4/cc1
> Filesystem type is: 9123683e
> File size of /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.4/cc1 is
> 9361528 (2286 blocks, blocksize 4096)
>  ext logical physical expected length flags
>    0       0  4542111              32
>    1      32  4542134  4542142     32
>    2      64  4573263  4542165     32

Ok, looks like we could be doing a little better job when compression is
on to build out a bigger extent.  This shouldn't be causing trouble on
an ssd at all but on your rotating disk it'll be slightly slower.

Still most of these extents are somewhat close together, this is roughly
what mount -o ssd (which is enabled automatically when we detect a
non-rotating drive) would try for.

The problematic files are going to have thousands of extents, this file
should be fine.

-chris