On Sun, Jul 31, 2011 at 9:51 AM, Peter Humphrey <pe...@humphrey.ukfsn.org> 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, 16MB > 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 must > be a considerable speed difference between its two ends. > > -- > Rgds > Peter 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. -- Poison [BLX] Joshua M. Murphy
