From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1P1bZ9-000291-Dk for garchives@archives.gentoo.org; Fri, 01 Oct 2010 09:06:07 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 337FCE0955; Fri, 1 Oct 2010 09:05:09 +0000 (UTC) Received: from mx01.admin-box.com (mx01.admin-box.com [78.47.249.108]) by pigeon.gentoo.org (Postfix) with ESMTP id D36C5E0955 for ; Fri, 1 Oct 2010 09:05:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx01.admin-box.com (Postfix) with ESMTP id 059E73072ACD for ; Fri, 1 Oct 2010 11:05:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mx01.admin-box.com Received: from mx01.admin-box.com ([127.0.0.1]) by localhost (mx01.admin-box.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmyEe2qVdgsz for ; Fri, 1 Oct 2010 11:05:06 +0200 (CEST) Received: from [192.168.0.137] (e178054064.adsl.alicedsl.de [85.178.54.64]) (Authenticated sender: daniel@troeder.de) by mx01.admin-box.com (Postfix) with ESMTPSA id C06E03072AB4 for ; Fri, 1 Oct 2010 11:05:05 +0200 (CEST) Message-ID: <4CA5A440.80601@admin-box.com> Date: Fri, 01 Oct 2010 11:05:04 +0200 From: Daniel Troeder User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100929 Thunderbird/3.1.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Normal disk speed? References: <201009301853.28825.volkerarmin@googlemail.com> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=BB9D4887; url=http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig51A8CFC402E61DF1D1E447AF" X-Archives-Salt: 8183c637-db1c-45f8-be03-319b0832a06c X-Archives-Hash: cac87eaff8710974a703e6711dc8e732 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig51A8CFC402E61DF1D1E447AF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/01/2010 03:12 AM, Adam Carter wrote: > Your harddisk seeks, everything is slow. >=20 > So does that then mean that my options are; > 1. Defragment, so there is less seeking > 2. Get an SSD >=20 > 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 " 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=3D1" 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 --=20 PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=3D0xBB9D4887&op=3Dg= et # gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887 --------------enig51A8CFC402E61DF1D1E447AF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkylpEAACgkQg3+4tbudSIeIxQCgmB6cjAKkHpDZU2okhHXOvAXh MWAAnj04ig0ljCpOe+XPD92cRXdnUOr3 =oz2I -----END PGP SIGNATURE----- --------------enig51A8CFC402E61DF1D1E447AF--