Re: [Bug-ddrescue] direct disk access will not read partial sector

[Scott D]

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
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/bug-ddrescue
>
>
> _______________________________________________
> Bug-ddrescue mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-ddrescue