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