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 1QnWqf-0000tw-GR for garchives@archives.gentoo.org; Sun, 31 Jul 2011 14:18:33 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6204821C297; Sun, 31 Jul 2011 14:18:21 +0000 (UTC) Received: from mail-vx0-f181.google.com (mail-vx0-f181.google.com [209.85.220.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 38ED521C025 for ; Sun, 31 Jul 2011 14:17:16 +0000 (UTC) Received: by vxh17 with SMTP id 17so4633870vxh.40 for ; Sun, 31 Jul 2011 07:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=g9EsI6LQBsaIrLgSqHHUidc8YUzhGTNcpH/9QVC4ed0=; b=w0oV6DKiNr8ZNW5P64fNuYVnUPHNqxvH3FfzBVKBYL3znh5iWDfIJ4obguDp8fcCrP mXy7Z83bCo6UFAA99RtIi04fymotyfyyq0KWE2+fnQnNwIFxjsnIDJcVgq+sqlCwAw44 nTL3Kodi1Ph3wZ9Ql5vQdikcIg22XEHYEeLIQ= 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.52.175.7 with SMTP id bw7mr3375552vdc.32.1312121836544; Sun, 31 Jul 2011 07:17:16 -0700 (PDT) Received: by 10.220.177.138 with HTTP; Sun, 31 Jul 2011 07:17:16 -0700 (PDT) In-Reply-To: <201107311451.36206.peter@humphrey.ukfsn.org> References: <20110725182047.GM30008@ns1.bonedaddy.net> <201107311213.09474.michaelkintzios@gmail.com> <201107311451.36206.peter@humphrey.ukfsn.org> Date: Sun, 31 Jul 2011 10:17:16 -0400 Message-ID: Subject: Re: OT: Re: [gentoo-user] X Freezes With Firefox on Many Post 2.6.38 Kernels From: Joshua Murphy To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 919d4b0e36fa74104c85a992a9fdea35 On Sun, Jul 31, 2011 at 9:51 AM, Peter Humphrey wrote: > On Sunday 31 July 2011 14:15:20 Joshua Murphy wrote: > >> Well, GParted, if I recall, does a couple checks to guess 'best' block >> size when cloning or moving a partition, but I'm really not sure how >> it does things when shrinking and shifting it sideways to a spot that >> overlaps with where it started... but based on the above, I would >> guess it really does do a bs of 512, or ar best, the cluster size of >> the file system it is moving (usually 4k), since it's moving the data >> stored there, not the whole partition, block for block. > > In fact it did run those tests, and it settled on a value of, I think, 16= MB > blocks. It then ran a read-only test of the entire file system, and only = then > started copying it. As it was moving the partition upwards by about half = its > occupied size, there was considerable overlap. That must mean that it > started with the highest-numbered block and worked steadily (very!) > downwards. > > I don't know where in the partition it ran its speed tests, but on a > partition that occupies almost all the physical disk, as it did, there mu= st > be a considerable speed difference between its two ends. > > -- > Rgds > Peter =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Linux Counter 5290, 1994-04-23 > > There probably is a fair chunk of difference in maximum speed the disk can work at on each end (I've even seen around a 20MB/s difference on several 160GB drives I've dealt with), but outside of some older drives that've been heavily abused in their lives, I'm not sure I've seen a sata drive that I've used my usual drive test (MHDD on a Hiren's bootable USB) on register below around 60MB/s on the slow end, and USB2's *theoretical* limit is 480Mb/s (60MB/s) ... real-world implementations rarely reach, let alone top, around 40MB/s, so disk speed variation across the disk is an unlikely source of the slowdown. More likely, it's the fact that parted has to start from the end, and work its way backwards, reading, writing, and verifying in separate rotations of the disk with no benefit from the drive's ability to stream a larger block into cache, since the whole process is backwards compared to the streaming read most drives are optimized for. Of course, this is all off the cuff conjecture on my part, including my assumptions about how parted approaches the whole task... mixed with a bit of anecdotal evidence on my end... but, makes for amusing conversation and contemplation, if nothing more substantial. I will point out that the newer advanced format WD 500GB blue's I've worked recently with pulled a consistent 120-110MB/s speed from end to end... when their older 320s usually peaked at around 85 or so. --=20 Poison [BLX] Joshua M. Murphy