On 10/01/2010 03:12 AM, Adam Carter wrote: > Your harddisk seeks, everything is slow. > > So does that then mean that my options are; > 1. Defragment, so there is less seeking > 2. Get an SSD > > Since 2 is too expensive for a decent size drive, is there anything i > can do about 1 without a backup and restore operation? Or will the > fragmentation be very small on reiser3 anyway (i mount with notail) so I > should just accept things as they are.
You can gain a significant performance win by choosing your fs carefully (and benchmarking). If you've got a fs with mostly files of "middle size" or "big size" like a root fs or media collection you can use ext4 or xfs and they will perform as good or better than reiser3 because they fragment less. In my experience reiser3 fragments strongly after a year or so of heavy usage. xfs has a online-defragment tool "xfs_fsr" in sys-fs/xfsdump that works very well and is officially supported. (No other fs has that, to my knowledge.) xfs is especially fast and efficient with "big" files (media files). ext4 and xfs perform well in most use cases and are actively developed. Read phoronix for benchmarks. :) If you've got lots of small files (<4kb) (like in a portage tree, mail or news server) you want to go with reiser3 or ext4. ext4 can be formatted with "-T news" to optimize for small files. The optimization is not in speed, but in small block size, to save disk space. As I read about the nice performance of btrfs with compression I tried it out two weeks ago. I'll be posting my benchmarks to this list soon. Until now I didn't have any problems, but still would not use btrfs on production systems. I store all my small portage files (/usr/portage, /var/cache/edb and /var/db/pkg - 215000 files) on a btrfs partition and have benchmarked it against reiser3 (which I was using before). --> double speed! (For example "emerge --metadata" and "rsync <yesterday-portage> <today-portage>" needs *half* the time on btrfs than reiser3!!!) For work I use VirtualBox a lot. I store my VM disk images on a xfs-fs, because I can defragment it, and fragmented VM disks are really slow. If you're working on a RAID or have a 4k-disk, you'll have to align your partitions to the stripe size. (See lots of long threads in this mailing list.) BTW: You wrote you mount with "notail". I hope you also use "noatime". This is _ultra_important_ if you have lots of metadata work (reading/modifying lots of files and/or their attributes, like in portage-trees). You probably never need atimes, no you should always mount all your filesystems with it. mkfs.xfs has an option "-l lazy-count=1" that helps in metadata heavy workloads. My point: The speed of your file access can vary a lot depending on the file system and its options. But the right file system to choose depends on your use case. In the end you'll have to benchmark... Bye, Daniel -- PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get # gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887
signature.asc
Description: OpenPGP digital signature
