On Thu, 03.02.2011 at 03:19:44 -0800, Xin LI wrote: > On Thu, Feb 3, 2011 at 3:07 AM, Gary Jennejohn > <gljennjohn_at_googlemail.com> wrote: > > On Wed, 2 Feb 2011 22:02:11 +0100 > > Ulrich Spörlein <uqs_at_spoerlein.net> wrote: > > > >> On Wed, 02.02.2011 at 12:04:58 -0800, Xin LI wrote: > >> > On 02/02/11 11:54, Alexander Best wrote: > >> > > so far dd(1) with a bs=2048 finished after: > >> > > > >> > > 4676648960 bytes transferred in 1639.108763 secs (2853166 bytes/sec) > >> > > >> > Just curious - how will recoverdisk(1) perform? I haven't tried it > >> > myself but it uses much larger window which could be faster. > >> > >> +1 for recoverdisk. I hacked it so that it will also cope with media > >> that has weird sectorsizes like 2352 bytes. It is awesome for reading > >> optical media now, thanks to retries, large read requests and the > >> ability to save progress (so you can try the failing sectors in another > >> drive). > >> > > > > And are these hacks available to the general public somewhere? > > I think recoverdisk already support using DIOCGSECTORSIZE to obtain > underlying sector size and I don't think it's really needed to hack > it? I think, maybe uqs_at_ mean one need to "hack" the CAM subsystem to > make the system believe that DVD have sectorsize of 2352 bytes for > some special purpose backup? Ah, sorry for giving the impression I was holding some patches back. They have already been committed to recoverdisk a long time ago (May 2006). The 2352 sector size is used by audio CDs and mode 2 data CDs, see http://en.wikipedia.org/wiki/CD-ROM . This was also fixed in 2006. Regards, Uli - migrated 99.99999% of data from his CD collection in 2006 and hasn't used optical media since ...Received on Thu Feb 03 2011 - 14:14:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:11 UTC