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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
