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 1P20gV-0005Kc-KF for garchives@archives.gentoo.org; Sat, 02 Oct 2010 11:55:24 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 37A57E07BC; Sat, 2 Oct 2010 11:55:09 +0000 (UTC) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by pigeon.gentoo.org (Postfix) with ESMTP id 14DE2E07BC for ; Sat, 2 Oct 2010 11:55:09 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id BAC0F3C7; Sat, 2 Oct 2010 07:55:08 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 02 Oct 2010 07:55:08 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:reply-to:mime-version:to:subject:references:in-reply-to:content-type; s=smtpout; bh=36XWZBtgB3l/zLhc8QjXA1BIvvA=; b=RfnFyvFUw+TnezK1OUs1sHQwdQpddogD2KKSCzx6ROsyRk/CowENPDneS15/vMcT8tRjpf0/YS5iaNvJ57vvNy0H636DW0SYBk+NCoJBkhJyc/JEsSHM39FD4HLil95nVuVRm3lftCEKlb+xqNZe2j9P8LjWMn+9OF6IaVLsdWo= X-Sasl-enc: aNzJrz5Z5Eik1Rcop+Vn6MBoXo4UEKAlXR5Trn5pvZEn 1286020507 Received: from [192.168.5.18] (lvps83-169-5-6.dedicated.hosteurope.de [83.169.5.6]) by mail.messagingengine.com (Postfix) with ESMTPSA id 84DC25E37AA for ; Sat, 2 Oct 2010 07:55:07 -0400 (EDT) Message-ID: <4CA71D8F.4010508@f_philipp.fastmail.net> Date: Sat, 02 Oct 2010 13:54:55 +0200 From: Florian Philipp User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100927 Lightning/1.0b3pre 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: <4CA59EFE.2020403@f_philipp.fastmail.net> <201010011823.01414.volkerarmin@googlemail.com> In-Reply-To: <201010011823.01414.volkerarmin@googlemail.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA2C3B883389F5429F8A20385" X-Archives-Salt: b298ecb4-d4f4-4ba3-ab58-52297968d1b4 X-Archives-Hash: cefeddf28dc6f054d1f21685fb771b3f This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA2C3B883389F5429F8A20385 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Am 01.10.2010 18:23, schrieb Volker Armin Hemmann: > On Friday 01 October 2010, Florian Philipp wrote: >> Am 01.10.2010 03:12, schrieb Adam Carter: >>> 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) s= o I >>> should just accept things as they are. >> >> To prevent fragmentation, try to always keep a decent amount of free >> space on each partition. That way, the FS driver can allocate space fo= r >> new files without too much fragmentation (a fragment every 2 MB or so >> doesn't really hurt performance). >=20 > you obviously never used a tape drive... >=20 >=20 Hehe, yep. :) While we're at the topic, we can do some basic math to show how bad fragmentation is. Symbols: s [MB]: total size t_f [s]: total read/write time with fragmentation t_nf [s]: total read/write time without fragmentation t_s [s]: seek time v [MB/s]: sequential throughput n [-]: number of fragments f [1/MB]: fragmentation (fragments per MB) e [-]: effectiveness (percentage) Assumptions: 1. Seek time is constant. For HDDs we can take an average value. Of course this doesn't work for tapes. They have a seek time which increases linearly with the distance between the fragments. 2. Throughput is constant. As I've stated in another post this is not true for HDDs but we can again take an average value. Formulas: s =3D v * t_nf //without fragmentation s =3D v * (t_f - n*t_s) //with fragmentation s =3D v*t_f - v*n*t_s t_f =3D (s + v*n*t_s)/v Without fragmentation we would have t_nf =3D s/v Now we can normalize the time to get the effectiveness e =3D t_nf / t_f e =3D s/v * v/(s * v*n*t_s) e =3D s/(s * v*n*t_s) e =3D 1/(n/s * t_s * v + 1) Nearly done. n/s is the fragmentation. Therefore we get: f =3D n/s e =3D 1/(f * t_s * v + 1) Great. Now we're done. For laptop HDDs I think a seek time of 12 ms (Wikipedia says so) and an average throughput of 50 MB/s are good values. When we plot effectiveness against fragmentation, we see that with one fragment every two MB we get around 77% effectiveness whereas with two two fragments every MB we already drop to 45%. Worst case would be one fragment per file system block. With 4kB blocks that's 256 fragments per MB. That means we drop to 0.65% effectiveness. The values seem drastic but are plausible: 50 MB/s sequential throughput and 12 ms seek time mean that in the time we need to do one seek operation, we could read 50*12e-3 =3D 0.6 MB. Hope this helps, Florian Philipp --------------enigA2C3B883389F5429F8A20385 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/ iEYEARECAAYFAkynHZUACgkQqs4uOUlOuU9K9ACggL+LQTHwsE/AYFaiJw4mZATs HW4AnRCObH1Mpj1zn+4z3N21PWNqh9C8 =gESY -----END PGP SIGNATURE----- --------------enigA2C3B883389F5429F8A20385--