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 1P20wt-0001XO-No for garchives@archives.gentoo.org; Sat, 02 Oct 2010 12:12:20 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E9AC6E07AA; Sat, 2 Oct 2010 12:11:48 +0000 (UTC) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id A63A4E07AA for ; Sat, 2 Oct 2010 12:11:48 +0000 (UTC) Received: by bwz1 with SMTP id 1so5421761bwz.40 for ; Sat, 02 Oct 2010 05:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=ClysbbbG9aI6KY7eSxMp6cmMXWP4uNpgrDJtjAvwBAk=; b=u+wFlac9dGbDWisplka7XssngX90rKYtpPZMhu45tO7yg4JwhdkxJHe83cFLiRD5ym RL+0wQRq8tPKSjJen+Mk/JWTMCMf1vdK0aPFx2uYMlLxr1Yl8GlAqAl4SBE0ucsmP866 fT+cHmoPyVfXpjyssVxVLOkEuQLtBvxuFDgy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; b=PVY05a/YLKgQT7tRameczFzRA1TQECRDfiQVYnxLW3LHzQuPdOtqkL7M9oUVlnonAu Wp7aCWbHMXrU+xG6HPqpoxqZEtAcZS6EFQrKkP/CMDrykd1LmMYPVgeiNL2Aa14HM+x7 w1F68NXqXEbxtVNepPV393CWFKZDcndCbn1R8= Received: by 10.204.118.202 with SMTP id w10mr5035536bkq.40.1286021508008; Sat, 02 Oct 2010 05:11:48 -0700 (PDT) Received: from energy.localnet (p5DCC00C7.dip0.t-ipconnect.de [93.204.0.199]) by mx.google.com with ESMTPS id s34sm1819528bkk.13.2010.10.02.05.11.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 Oct 2010 05:11:47 -0700 (PDT) From: Volker Armin Hemmann To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Normal disk speed? Date: Sat, 2 Oct 2010 14:11:49 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.34.7r4; KDE/4.5.1; x86_64; ; ) References: <201010011823.01414.volkerarmin@googlemail.com> <4CA71D8F.4010508@f_philipp.fastmail.net> In-Reply-To: <4CA71D8F.4010508@f_philipp.fastmail.net> 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 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010021411.49279.volkerarmin@googlemail.com> X-Archives-Salt: c1265207-9e85-484d-97de-1cbc6c1e5eee X-Archives-Hash: e40cb301fa5a0eab54a1253d04840327 On Saturday 02 October 2010, Florian Philipp wrote: > 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) so > >>> 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 for > >> new files without too much fragmentation (a fragment every 2 MB or so > >> doesn't really hurt performance). > > > > you obviously never used a tape drive... > > 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. I think you misunderstood my remark. Tapes try to stream. Take an old DLT drive with 5-10mb/sec streaming speed. Slow, isn't it? But when you do a backup on such an old tape even with a modern harddisk you have problems keeping it streaming. As soon as you hit a directory with many small files - like ~/Mail or /usr/portage you are screwed. Yes, you have wonderfull 100mb/sec when you read a big, fat file. Or a single small file. But when you have houndreds, thousands or hundreds of thousands of small files, harddisks suck. And your tape drive has to stop and rewind every couple of seconds because your harddisks were not able to keep up the required 10mb/sec. Trueley pathetic. Besides, seek times are not constant ;)