| 1 |
On Sunday 31 July 2011 14:15:20 Joshua Murphy wrote: |
| 2 |
|
| 3 |
> Well, GParted, if I recall, does a couple checks to guess 'best' block |
| 4 |
> size when cloning or moving a partition, but I'm really not sure how |
| 5 |
> it does things when shrinking and shifting it sideways to a spot that |
| 6 |
> overlaps with where it started... but based on the above, I would |
| 7 |
> guess it really does do a bs of 512, or ar best, the cluster size of |
| 8 |
> the file system it is moving (usually 4k), since it's moving the data |
| 9 |
> stored there, not the whole partition, block for block. |
| 10 |
|
| 11 |
In fact it did run those tests, and it settled on a value of, I think, 16MB |
| 12 |
blocks. It then ran a read-only test of the entire file system, and only then |
| 13 |
started copying it. As it was moving the partition upwards by about half its |
| 14 |
occupied size, there was considerable overlap. That must mean that it |
| 15 |
started with the highest-numbered block and worked steadily (very!) |
| 16 |
downwards. |
| 17 |
|
| 18 |
I don't know where in the partition it ran its speed tests, but on a |
| 19 |
partition that occupies almost all the physical disk, as it did, there must |
| 20 |
be a considerable speed difference between its two ends. |
| 21 |
|
| 22 |
-- |
| 23 |
Rgds |
| 24 |
Peter Linux Counter 5290, 1994-04-23 |
Archives