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 1MYOjB-0002qK-BF for garchives@archives.gentoo.org; Tue, 04 Aug 2009 18:27:13 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E6314E02AB; Tue, 4 Aug 2009 18:26:26 +0000 (UTC) Received: from mail-pz0-f181.google.com (mail-pz0-f181.google.com [209.85.222.181]) by pigeon.gentoo.org (Postfix) with ESMTP id A817BE02C8 for ; Tue, 4 Aug 2009 18:26:26 +0000 (UTC) Received: by pzk11 with SMTP id 11so2695587pzk.10 for ; Tue, 04 Aug 2009 11:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Y7LFbHOTFj7nJKZWcZLIjGGoA9Kmh8xRzE2oj/mvFEs=; b=MGVxRJNJOxe9Up+j1sA6GOtP2QAwLHg7fEuT1YBsGD+0isj0flIIaY740q8dUuxrR6 lNYMy413RI2Bm+H0aDwhmAP1rySLu3vicgUQFqGEab26ZasA0b/ZbySBP13itybbLfT2 5jVxz+6O+DWn4Acr2+DG0b4HZ4iaFxG1BSJJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=E6/mN3tqcpo/VVFN0t1fnOqiUJT/ErJHeGI4NBf7FNh0E+m8xaVg8dZImLsSO05Pgm FCO9OXjAp8GUM/0H+XjVPf8IJo+lQxRJsCFRAr5CObSli2f8/VSxpbgQaccXEQB7ux/l xgQVVd+z83yKqXO1RI4J0XTzihq/X/KVRMJjE= 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 Received: by 10.115.89.6 with SMTP id r6mr9019126wal.135.1249410386271; Tue, 04 Aug 2009 11:26:26 -0700 (PDT) In-Reply-To: <58965d8a0908031801xcfd2a8ex433705ed93cf589c@mail.gmail.com> References: <49bf44f10908031322y2b06b5ffx76ecb27092b9edfa@mail.gmail.com> <58965d8a0908031405g1cf04cbarc77d588072fdbe89@mail.gmail.com> <49bf44f10908031648g65d405b0i78beead0ea0b8ab9@mail.gmail.com> <58965d8a0908031801xcfd2a8ex433705ed93cf589c@mail.gmail.com> Date: Tue, 4 Aug 2009 11:26:26 -0700 Message-ID: <49bf44f10908041126h3e991956ta3a3fd397778ff4f@mail.gmail.com> Subject: Re: [gentoo-user] Anybody tried shake defragmenter? From: Grant To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 2316f23a-cd9a-47c5-922c-79af1f7fcb7c X-Archives-Hash: 727c6341c9e149e0026f8aa25637c555 >>>> I know Linux systems aren't supposed to become fragmented, but I've >>>> also read that it can happen eventually. =A0I'm on ext3. =A0I've read = that >>>> ext4 will have a defragmenter but that it doesn't have one yet. >>> >>> It's not that they aren't supposed to become fragmented, it is that >>> they try to avoid it. There is a big difference, and things like >>> streaming writes (downloads, bittorrents, etc) can cause extreme >>> fragmentation. >> >> Yeah, that's when I'm hearing the HD access I didn't hear before. =A0I >> run miro and it's downloading several torrents all the time. =A0It never >> made a sound before, but now there's a rhythmic grinding sound when >> miro is running, maybe because the HD is more full now. =A0Could shake >> help with this? =A0To find out, should I be running it on the partially >> downloaded torrents? > > Well, bittorent does not download in sequential order, so it is > constantly doing random reads and writes. You may not be able to avoid > the HD grinding during this kind of activity. Download to a RAM drive > or SSD or something perhaps. > > Fragmentation definitely gets worse the nearer you are to full (which > for me is always). I have seen very small files with hundreds of > fragments as I live at 99% of my space used. They say a hard drive has > 2 states: new and full :) > > It certainly wouldn't hurt to defrag the partial files, though you may > want to pause your download before doing it (I don't know how much > locking/blocking may occur on in-use files). Some bittorrent clients > have an option to write a placeholder file; this is supposed to > prevent fragmentation since it's allocating the space for the whole > file immediately. Vuze is what I use, it calls this option "allocate > and zero new files on creation". The down-side is it could take a > while to initialize if you're downloading something huge, especially > if you're saving to a network or USB hard drive that's not very fast. Is there any tool available to show which files are being written to any any given time? iotop is great for watching the I/O rate and which process is responsible, but sometimes I wonder which files are being written. For example, miro is showing a constant 3.5Mbps write in iotop, and I only have 50kbps downloading and 30kbps uploading. I'd really like to know what is being written to. Here's how I'm running shake, please let me know if you would modify this to work on my noisy drive problem: shake -vX --new 0 --old 0 --bigsize 0 folder Does anyone know what these headers indicate (FRAGC and SHOCKED for example)? There is no info in man or on the homepage: IDEAL START END FRAGC CRUMBC AGE SHOCKED NAME - Grant