I am pointing out a difference between using or not using the direct
disk access option. If you don't use the -d option, the full sector gets
read and the unrequested data is removed anyway, so ddrescue already
does what you don't want it to do. You are correct that the data can be
discarded later. However, let me give a possible scenario example where
it could make a difference for someone that doesn't know any better.
ddrescue -d -i 0 -s 1000000 /dev/sda image logfile
ddrescue -d -i 1000000 -s 1000000 /dev/sda image logfile
ddrescue -d -i 2000000 -s 1000000 /dev/sda image logfile
or
ddrescue -d -i 0 -s 1M /dev/sda image logfile
ddrescue -d -i 1M -s 1M /dev/sda image logfile
ddrescue -d -i 2M -s 1M /dev/sda image logfile
Both these should read 3 million bytes. However, it will report 3 read
errors on sectors it did not try because the start or end did not fall
on a sector boundary.
ddrescue -d -i 0 -s 1Mi /dev/sda image logfile
ddrescue -d -i 1Mi -s 1Mi /dev/sda image logfile
ddrescue -d -i 2Mi -s 1Mi /dev/sda image logfile
This will work since it is using the 1024 base.
If it is really not a good idea to change ddrescue, then maybe this
should be stated in the manual in the direct disk access section. I had
to find out the hard way.
On 11/30/2012 7:06 AM, Felix Ehlermann wrote:
Dear Scott,
as far as I have understood how (magnetic) hard disk drives work, it
is not possible to read fractions of a sector because of the way the
data is stored on the disk.
(Unless using vendor specific commands maybe..)
There is a very nice white paper by Western Digital which explains how
data is stored in 512 and 4096 byte sector format drives:
http://www.wdc.com/wdproducts/library/WhitePapers/ENG/2579-771430.pdf
(or http://www.wdc.com/wdproducts/library/?id=216&type=87 for other
languages)
As ddrescue's goal is usually to recover as much data from a damaged
or failing drive as possible I would not expect it to discard any data
it has already read successfully.
Discarding data can be done effectively with other tools at a later
point of time - as you already explained.
I think that adding the possibility to discard such "unwanted" bytes
would needlessly complicate the implementation of ddrescue without any
gain for ddrescues main usecase which is recovering as much data as
possible and not discarding recovered data.
So as a fellow user of ddrescue I would like to oppose your suggestion
of adding this feature since requesting such "unaligned" reads is
likely to be undesired by the user as the hard drive would have to
read the entire sector anyway.
Kind Regards
Felix
On 30.11.2012 07:14, Scott Dwyer wrote:
I have found a workaround for me by reading the full allocated file
and then using truncate to cut the file to proper length, although
this reads a few extra sectors. But I would think that ddrescue
should try to read a whole sector and only write what is asked of, as
opposed to not try at all. I am not sure what you mean by domain
fragmentation though.
On 11/28/2012 2:54 PM, Antonio Diaz Diaz wrote:
Hello Scott,
Scott Dwyer wrote:
I do not know if this would be considered a bug, or just the nature
of the direct disk access. When using the -d option, ddrescue will
not attempt to read data that does not start or end on a sector
boundary.
I thinh it is the nature of direct disk access. The kernel does not
accept such partial sector reads.
Of course partial reads could be faked by reading the whole sector
and writing only the requested part. AFAIK neither linux nor glibc
implement this with direct disk access. I am not sure if it would be
a good idea for ddrescue to implement it or not. It may mean reading
the same sector more than once in extreme cases of domain
fragmentation. But I guess such domains are even less normal that
what you are doing. :-)
Regards,
Antonio.
_______________________________________________
Bug-ddrescue mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-ddrescue
_______________________________________________
Bug-ddrescue mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-ddrescue
_______________________________________________
Bug-ddrescue mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-ddrescue
