1 |
On Sun, Jul 31, 2011 at 9:51 AM, Peter Humphrey |
2 |
<peter@××××××××××××××.org> wrote: |
3 |
> On Sunday 31 July 2011 14:15:20 Joshua Murphy wrote: |
4 |
> |
5 |
>> Well, GParted, if I recall, does a couple checks to guess 'best' block |
6 |
>> size when cloning or moving a partition, but I'm really not sure how |
7 |
>> it does things when shrinking and shifting it sideways to a spot that |
8 |
>> overlaps with where it started... but based on the above, I would |
9 |
>> guess it really does do a bs of 512, or ar best, the cluster size of |
10 |
>> the file system it is moving (usually 4k), since it's moving the data |
11 |
>> stored there, not the whole partition, block for block. |
12 |
> |
13 |
> In fact it did run those tests, and it settled on a value of, I think, 16MB |
14 |
> blocks. It then ran a read-only test of the entire file system, and only then |
15 |
> started copying it. As it was moving the partition upwards by about half its |
16 |
> occupied size, there was considerable overlap. That must mean that it |
17 |
> started with the highest-numbered block and worked steadily (very!) |
18 |
> downwards. |
19 |
> |
20 |
> I don't know where in the partition it ran its speed tests, but on a |
21 |
> partition that occupies almost all the physical disk, as it did, there must |
22 |
> be a considerable speed difference between its two ends. |
23 |
> |
24 |
> -- |
25 |
> Rgds |
26 |
> Peter Linux Counter 5290, 1994-04-23 |
27 |
> |
28 |
> |
29 |
|
30 |
There probably is a fair chunk of difference in maximum speed the disk |
31 |
can work at on each end (I've even seen around a 20MB/s difference on |
32 |
several 160GB drives I've dealt with), but outside of some older |
33 |
drives that've been heavily abused in their lives, I'm not sure I've |
34 |
seen a sata drive that I've used my usual drive test (MHDD on a |
35 |
Hiren's bootable USB) on register below around 60MB/s on the slow end, |
36 |
and USB2's *theoretical* limit is 480Mb/s (60MB/s) ... real-world |
37 |
implementations rarely reach, let alone top, around 40MB/s, so disk |
38 |
speed variation across the disk is an unlikely source of the slowdown. |
39 |
More likely, it's the fact that parted has to start from the end, and |
40 |
work its way backwards, reading, writing, and verifying in separate |
41 |
rotations of the disk with no benefit from the drive's ability to |
42 |
stream a larger block into cache, since the whole process is backwards |
43 |
compared to the streaming read most drives are optimized for. Of |
44 |
course, this is all off the cuff conjecture on my part, including my |
45 |
assumptions about how parted approaches the whole task... mixed with a |
46 |
bit of anecdotal evidence on my end... but, makes for amusing |
47 |
conversation and contemplation, if nothing more substantial. I will |
48 |
point out that the newer advanced format WD 500GB blue's I've worked |
49 |
recently with pulled a consistent 120-110MB/s speed from end to end... |
50 |
when their older 320s usually peaked at around 85 or so. |
51 |
|
52 |
-- |
53 |
Poison [BLX] |
54 |
Joshua M. Murphy |