Phillip Susi wrote:
On 4/29/2010 4:22 PM, Curtis Gedak wrote:
For all other file systems, GParted has implemented a block by block
copy operation. Please note that I believe early releases of GParted
used 'dd' only for copying partitions, not _moving_ partitions.
Does it currently use large ( 4-8 MB maybe ) buffers with O_DIRECT?
That is much faster than transferring 4kb at a time through the kernel
buffer cache.
The GParted code in the git repository will benchmark block sizes from 1
MB up to 16 MB doubling the size for each test. It will choose the copy
operation that takes the shortest amount of time. You can review the
code in GParted_Core.cc by searching for "optimal block size".
The libparted functions ped_device_read and ped_device_write are used to
perform the read and write operations respectively.
The GParted move code does not contain intelligence regarding the file
system. While performing a move GParted copies each and every block in
the partition regardless of whether the block contains data.
Would you be interested in improving this to skip the unused blocks?
Asking e2fslibs for the allocation bitmap is pretty straight forward.
Interested? Yes.
Ready to do it? No, as I have many more higher priority bug fixes and
enhancements to make to the GParted code.
Perhaps you would consider writing a patch? ;-)
GParted first performs a read of the entire partition, prior to moving
the partition in an attempt to avoid moving a partition containing bad
blocks.
Outch, so it reads the entire thing twice? Why? Why not just warn the
user that there were some bad sectors detected and fill the destination
with zeroes?
Two reasons for performing a test read come to mind:
1) If bad sectors are detected on a drive, then there is still a chance
for the user to recover the data. This can be done by repeatedly trying
to read the bad sector until the read operation finally succeeds. I
have personally done this to recover data from a commercial database. A
higher number of recovery schemes are available if the partition is not
moved.
2) If bad sectors are detected, then I personally would suggest copying
the data to another drive to avoid further data loss. Moving the
partition does not address the underlying problem of a hard drive failing.
3) We try our best in GParted to protect data as best we can. The
extra step of reading first prior to performing a move operation does
provide some additional security because we avoid manipulating data on a
partition with bad sectors.
Your alternative suggestion is certainly a valid, if not desirable
option. The challenge comes down to which enhancements to make in the
time that we have. At the moment I have my hands full with other
changes, with support for devices with sector sizes greater than 512
bytes foremost on my mind.
_______________________________________________
parted-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/parted-devel
