increasing dd disk to disk transfer rate
My notebooks' hard disk, a Hitachi Travelstar 80 GB starts to develop read errors. I have FreeBSD and Win XP on that disk. Although FreeBSD ist still working , the errors in the Windows partition are causing Windows do ask for a filesystem check nearly everytime I reboot the computer. One time the error was in the hibernate.sys file, which impedes powering up quickly after a hibernate. Anyway, I decided to buy a second identical hard disk and tried to block by block copy the old disk to the new one using dd if=/dev/ad2 of=/dev/ad3 conv=noerror The process is running now since yesterday evening and it is at 53 MB at a transfer rate of about 1.1 MB/s. In case the the result being unusable I would like to find a way to make this copying faster. Any disk expert here? My motherboard is an ASUS P4S8X with an on board promise controller (currently not in use). System disk is on IDE1 and the two 80GB disks are master/slave on IDE2 bus. I wonder wether I could get better results (transfer rate) when attaching the disks to copy to the promise IDE bus. And another question: Is there a way to tweak the driver (be it the FreeBSD promise driver or the normal ata driver) to use more retries on errors so that I have the chance to copy everything or nearly everything of the already degrading hard disk? -- Chris Christoph P. U. Kukulies kuku_at_kukulies.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
On Thu, Jan 12, 2006 at 10:48:38AM +0100 I heard the voice of Christoph Kukulies, and lo! it spake thus: > > dd if=/dev/ad2 of=/dev/ad3 conv=noerror Give it a bigger blocksize (say, bs=1m or so) and it'll go a **LOT** faster. > My motherboard is an ASUS P4S8X with an on board promise controller > (currently not in use). System disk is on IDE1 and the two 80GB > disks are master/slave on IDE2 bus. You'll get much better results by having each drive be master on its own bus. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
Christoph Kukulies wrote: My notebooks' hard disk, a Hitachi Travelstar 80 GB starts to develop read errors. I have FreeBSD and Win XP on that disk. Although FreeBSD ist still working , the errors in the Windows partition are causing Windows do ask for a filesystem check nearly everytime I reboot the computer. One time the error was in the hibernate.sys file, which impedes powering up quickly after a hibernate. Anyway, I decided to buy a second identical hard disk and tried to block by block copy the old disk to the new one using dd if=/dev/ad2 of=/dev/ad3 conv=noerror Specify a larger block size - the default is 512bytes, which is not efficient for what you are doing. Maybe 1mb would be the right number. The process is running now since yesterday evening and it is at 53 MB at a transfer rate of about 1.1 MB/s. In case the the result being unusable I would like to find a way to make this copying faster. Any disk expert here? My motherboard is an ASUS P4S8X with an on board promise controller (currently not in use). System disk is on IDE1 and the two 80GB disks are master/slave on IDE2 bus. Also, put the disks on separate IDE busses - one disk on ide1, the other on ide2. This will help a lot.. I wonder wether I could get better results (transfer rate) when attaching the disks to copy to the promise IDE bus. And another question: Is there a way to tweak the driver (be it the FreeBSD promise driver or the normal ata driver) to use more retries on errors so that I have the chance to copy everything or nearly everything of the already degrading hard disk? Not sure about that.. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
Christoph Kukulies wrote: Anyway, I decided to buy a second identical hard disk and tried to block by block copy the old disk to the new one using dd if=/dev/ad2 of=/dev/ad3 conv=noerror The process is running now since yesterday evening and it is at 53 MB at a transfer rate of about 1.1 MB/s. The default block size for dd is 512 bytes, meaning dd will read 512 bytes from one disk and write them to the other before reading again. This is SLOW. You need to specify a larger block size to use it effectively, like adding "bs=1m" argument to dd (which will make it use 1 MB blocks). Also, you should probably add "sync" to your "conv" argument, see the manual page of dd. I don't know if using "sync" will produce a full 1 MB of zeros when a bad sector is encountered - I hope someone else will clarify this :) Btw. I don't think this is the right group for your question - in the future use [EMAIL PROTECTED] or [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
> My notebooks' hard disk, a Hitachi Travelstar 80 GB starts to
> develop read errors.
Since you are using a modern disk, you should check your smart counters. I
know how to do it on NetBSD, and I believe the command is also available on
FreeBSD. First, you have to turn on the smart (S.M.A.R.T.) stuff on the
hard-disk.
Then you can poll the hard disk and have counters reported back to you with
precious information about errors :)
Here is what I get from atactl on NetBSD :
{/root}
[root][1] atactl wd0 smart status
SMART supported, SMART enabled
id value thresh crit collect reliability descriptionraw
1 100 51 yes online positiveRaw read error rate0
3 100 25 yes online positiveSpin-up time 2944
4 1000 no online positiveStart/stop count 453
5 253 10 yes online positiveReallocated sector count 0
7 2530 no online positiveSeek error rate0
8 2530 no offline positiveSeek time performance 0
9 1000 no online positivePower-on hours count 7010
10 2530 no online positiveSpin retry count 0
12 1000 no online positiveDevice power cycle count 9
191 1000 no online positiveGsense error rate 35
194 1120 no online positiveTemperature42
195 1000 no online positiveHardware ECC Recovered
1981492
196 2530 no online positiveReallocated event count0
197 2530 no online positiveCurrent pending sector 0
198 2530 no offline positiveOffline uncorrectable 0
199 2000 no online positiveUltra DMA CRC error count 0
200 1000 no online positiveWrite error rate 0
201 2530 no online positiveSoft read error rate 0
223 2530 no online positiveLoad/unload retry count0
225 1000 no online positiveLoad/unload cycle count5513
255 1000 no online positiveUnknown0
So by checking your own counters, you might get hints from the hardware that
something is wrong there.
Then, there is a web page with tools from Hitachi (IBM) that allow you to
boot and check your disk :
http://www.hitachigst.com/hdd/support/download.htm
Which such tools, you can have access to some functions that are not
available from our beloved BSD like turning ON the "check the noise you do
and try to be quiet" option :)
The feature tool will let you do that :
Change the drive Automatic Acoustic Management settings to the:
* Lowest acoustic emanation setting (Quiet Seek Mode), or
* Maximum performance level (Normal Seek Mode).
I was using a disk like yours on my Thinkpad X30. I replaced it with a
Samsung which has the same kind of tools available and usually in the form
of bootable floppies.
Hope this will help !
--
unzip ; strip ; touch ; grep ; find ; finger ; mount ; fsck ; more ; yes ;
fsck ; umount ; sleep
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
In the last episode (Jan 12), Christoph Kukulies said: > My notebooks' hard disk, a Hitachi Travelstar 80 GB starts to develop > read errors. I have FreeBSD and Win XP on that disk. Although FreeBSD > ist still working , the errors in the Windows partition are causing > Windows do ask for a filesystem check nearly everytime I reboot the > computer. One time the error was in the hibernate.sys file, which > impedes powering up quickly after a hibernate. > > Anyway, I decided to buy a second identical hard disk and tried to > block by block copy the old disk to the new one using > > dd if=/dev/ad2 of=/dev/ad3 conv=noerror > > The process is running now since yesterday evening and it is at 53 MB > at a transfer rate of about 1.1 MB/s. Everybody has mentioned the first obvious fix: raise your blocksize from the default 512 bytes. The second fix addresses the problem that with a single dd, you are either reading or writing. If you pipe the first dd into a second one, it'll let you run at the max speed of the slowest device. dd if=/dev/ad2 conv=noerror,sync bs=64k | dd of=/dev/ad3 bs=64k -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
> In the last episode (Jan 12), Christoph Kukulies said: > > My notebooks' hard disk, a Hitachi Travelstar 80 GB starts to develop > > read errors. I have FreeBSD and Win XP on that disk. Although FreeBSD > > ist still working , the errors in the Windows partition are causing > > Windows do ask for a filesystem check nearly everytime I reboot the > > computer. One time the error was in the hibernate.sys file, which > > impedes powering up quickly after a hibernate. > > > > Anyway, I decided to buy a second identical hard disk and tried to > > block by block copy the old disk to the new one using > > > > dd if=/dev/ad2 of=/dev/ad3 conv=noerror > > > > The process is running now since yesterday evening and it is at 53 MB > > at a transfer rate of about 1.1 MB/s. > > Everybody has mentioned the first obvious fix: raise your blocksize > from the default 512 bytes. The second fix addresses the problem that > with a single dd, you are either reading or writing. If you pipe the > first dd into a second one, it'll let you run at the max speed of the > slowest device. > > dd if=/dev/ad2 conv=noerror,sync bs=64k | dd of=/dev/ad3 bs=64k So now on the new disk he has files with random blocks of zeroes and *no* error indication of which files are so trashed. This is asking for trouble. Silent erros are worse. He ought to do a file level copy, not disk level copy on unix. That way he knows *which* files are trashed and can do a better job of recovering. Assuming he has backups. Windows is pickier about things but I am sure there are windows tools that will handle all that and allow more retries. dd is the *wrong* tool for what he wants to do. If it were upto me first I'd backup all the data I may need; using multiple retries and all that and then install freebsd from scratch on the new *bigger* disk. Perfect time for house cleaning and removing all those ports you don't use any more! As for windows I'd use the recovery disk and in effect reinstall windows from scrach and then reinstall all apps and move over my data files. [What I actually do is to run win2k under qemu on my laptop. Good enough for what I need it for] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
Bakul Shah wrote: In the last episode (Jan 12), Christoph Kukulies said: dd if=/dev/ad2 conv=noerror,sync bs=64k | dd of=/dev/ad3 bs=64k So now on the new disk he has files with random blocks of zeroes and *no* error indication of which files are so trashed. This is asking for trouble. Silent erros are worse. He ought to do a file level copy, not disk level copy on unix. That way he knows *which* files are trashed and can do The problem is, FreeBSD panics when it encounters bad sectors in filesystem metadata. I had the same situation ~a month ago and gave up, restoring from old backups. It will also probably panic on corrupted or zeroed metadata, but at least it's on a readable disk... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
> Bakul Shah wrote: > >>In the last episode (Jan 12), Christoph Kukulies said: > > >>dd if=/dev/ad2 conv=noerror,sync bs=64k | dd of=/dev/ad3 bs=64k > > > > > > So now on the new disk he has files with random blocks of > > zeroes and *no* error indication of which files are so > > trashed. This is asking for trouble. Silent erros are > > worse. > > > > He ought to do a file level copy, not disk level copy on > > unix. That way he knows *which* files are trashed and can do > > The problem is, FreeBSD panics when it encounters bad sectors in > filesystem metadata. I had the same situation ~a month ago and gave up, > restoring from old backups. It will also probably panic on corrupted or > zeroed metadata, but at least it's on a readable disk... Good point. Would fsdb help? If not someone ought to extend it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
Bakul Shah wrote: Bakul Shah wrote: In the last episode (Jan 12), Christoph Kukulies said: dd if=/dev/ad2 conv=noerror,sync bs=64k | dd of=/dev/ad3 bs=64k So now on the new disk he has files with random blocks of zeroes and *no* error indication of which files are so trashed. This is asking for trouble. Silent erros are worse. He ought to do a file level copy, not disk level copy on unix. That way he knows *which* files are trashed and can do The problem is, FreeBSD panics when it encounters bad sectors in filesystem metadata. I had the same situation ~a month ago and gave up, restoring from old backups. It will also probably panic on corrupted or zeroed metadata, but at least it's on a readable disk... Good point. Would fsdb help? If not someone ought to extend it. I think after the dd is done, fsck should be run against the affected filesystems, which should take care of most of the issues. The OP's question was how to make dd faster, not really how to get the data across safely. :) Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
> I think after the dd is done, fsck should be run against the affected > filesystems, which should take care of most of the issues. For metadata yes, but not for normal file data. He wouldn't even know what got trashed. > The OP's question was how to make dd faster, not really how to get the > data across safely. :) Sometime you have to answer the question they should've asked! That is what a diagnostician has to do. Fix the cause. Not the symptom. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
On Thu, 2006-Jan-12 10:48:38 +0100, Christoph Kukulies wrote: >dd if=/dev/ad2 of=/dev/ad3 conv=noerror > >The process is running now since yesterday evening and it is at 53 MB >at a transfer rate of about 1.1 MB/s. > >In case the the result being unusable I would like to find a way to make this >copying faster. Note that whilst increasing the DD blocksize will speed up the transfer, it will also increase the amount of collateral damage when a hard error occurs. If you rummage around the ports or tools tree, you'll find a utility (its name escapes me but I believe it was written by phk) that is designed to do disk-to-disk recovery - it copys data in big slabs until it gets an error and then works around the faulty area block by block. You should also install /usr/ports/sysutils/smartmontools - this handles S.M.A.R.T. >Is there a way to tweak the driver (be it the FreeBSD promise driver >or the normal ata driver) to use more retries on errors so that I >have the chance to copy everything or nearly everything of the already >degrading hard disk? A quick look at the ata driver suggests that there are a number of 'retry' and 'retries' variables/fields. I suspect you could increase the number of retries if you wanted to patch the driver. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
Moin moin, wie geht's :-) Christoph Kukulies wrote on Thu, Jan 12, 2006 at 10:48:38AM +0100: > > My notebooks' hard disk, a Hitachi Travelstar 80 GB starts to develop read > errors. I have FreeBSD and Win XP on that disk. Although FreeBSD ist still > working , the errors in the Windows partition are causing Windows do ask for > a > filesystem check nearly everytime I reboot the computer. One time the > error was in the hibernate.sys file, which impedes powering up quickly after > a hibernate. > > Anyway, I decided to buy a second identical hard disk and tried to > block by block copy the old disk to the new one using > > dd if=/dev/ad2 of=/dev/ad3 conv=noerror > > The process is running now since yesterday evening and it is at 53 MB > at a transfer rate of about 1.1 MB/s. /usr/ports/mis/cstream is a dd-like tool which allows you to specify that it buffers up megabyte of input before writing to the output. You need that because you are on the same bus with both disks. Use the -B and -b options with some high values. Experiment with the -c option. > Is there a way to tweak the driver (be it the FreeBSD promise driver > or the normal ata driver) to use more retries on errors so that I > have the chance to copy everything or nearly everything of the already > degrading hard disk? Just retrying the same block probably doesn't do it. You'll be more successful by seeking to move the head around before retrying. Martin -- %%% Martin Cracauerhttp://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
On Fri, Jan 13, 2006 at 08:13:00 +1100, Peter Jeremy wrote: > On Thu, 2006-Jan-12 10:48:38 +0100, Christoph Kukulies wrote: > >dd if=/dev/ad2 of=/dev/ad3 conv=noerror > > > >The process is running now since yesterday evening and it is at 53 MB > >at a transfer rate of about 1.1 MB/s. > > > >In case the the result being unusable I would like to find a way to make this > >copying faster. > > Note that whilst increasing the DD blocksize will speed up the > transfer, it will also increase the amount of collateral damage when a > hard error occurs. If you rummage around the ports or tools tree, > you'll find a utility (its name escapes me but I believe it was > written by phk) that is designed to do disk-to-disk recovery - it > copys data in big slabs until it gets an error and then works around > the faulty area block by block. It's called 'recoverdisk', and is in src/tools/tools/recoverdisk. I used it to copy a friend's hard drive, and it worked well. (Although the supposedly 'bad' disk didn't turn out to have any bad sectors.) Ken -- Kenneth Merry [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
Ivan Voras wrote this message on Thu, Jan 12, 2006 at 18:48 +0100: > Bakul Shah wrote: > >>In the last episode (Jan 12), Christoph Kukulies said: > > >>dd if=/dev/ad2 conv=noerror,sync bs=64k | dd of=/dev/ad3 bs=64k > > > > > >So now on the new disk he has files with random blocks of > >zeroes and *no* error indication of which files are so > >trashed. This is asking for trouble. Silent erros are > >worse. > > > >He ought to do a file level copy, not disk level copy on > >unix. That way he knows *which* files are trashed and can do > > The problem is, FreeBSD panics when it encounters bad sectors in > filesystem metadata. I had the same situation ~a month ago and gave up, > restoring from old backups. It will also probably panic on corrupted or > zeroed metadata, but at least it's on a readable disk... Recovery can be possible with ffsrecov.py: http://people.freebsd.org/~jmg/ffsrecov/ -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
* Peter Jeremy <[EMAIL PROTECTED]> [2006-01-13 08:13 +1100]: > Note that whilst increasing the DD blocksize will speed up the > transfer, it will also increase the amount of collateral damage when a > hard error occurs. If you rummage around the ports or tools tree, > you'll find a utility (its name escapes me but I believe it was > written by phk) that is designed to do disk-to-disk recovery - it > copys data in big slabs until it gets an error and then works around > the faulty area block by block. sysutils/dd_rescue I haven't tried it, but pkg-descr sounds promising. Nicolas -- http://www.rachinsky.de/nicolas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
Thanks, folks, for the interesting contributions. I really should have marked the subject "OT" but there spring up a lot of interesting ideas. On Fri, Jan 13, 2006 at 08:13:00AM +1100, Peter Jeremy wrote: > On Thu, 2006-Jan-12 10:48:38 +0100, Christoph Kukulies wrote: > >dd if=/dev/ad2 of=/dev/ad3 conv=noerror > > > >The process is running now since yesterday evening and it is at 53 MB > >at a transfer rate of about 1.1 MB/s. > > > >In case the the result being unusable I would like to find a way to make this > >copying faster. > > Note that whilst increasing the DD blocksize will speed up the > transfer, it will also increase the amount of collateral damage when a > hard error occurs. If you rummage around the ports or tools tree, > you'll find a utility (its name escapes me but I believe it was > written by phk) that is designed to do disk-to-disk recovery - it /usr/src/tools/tools/recoverdisk I fired up this tool yesterday night and it is still running. Ah yes, it runs forever unless it empties the queued failed block reads. It writes out a line of numbers (which are a bit difficult to understand). I think the suggestion to do a filewise recovery would be the best since it will be very unlikely > copys data in big slabs until it gets an error and then works around > the faulty area block by block. > > You should also install /usr/ports/sysutils/smartmontools - this > handles S.M.A.R.T. Yes, but what would smart help me further with recovery? > > >Is there a way to tweak the driver (be it the FreeBSD promise driver > >or the normal ata driver) to use more retries on errors so that I > >have the chance to copy everything or nearly everything of the already > >degrading hard disk? > > A quick look at the ata driver suggests that there are a number of > 'retry' and 'retries' variables/fields. I suspect you could increase > the number of retries if you wanted to patch the driver. Thanks for the help. -- Chris Christoph P. U. Kukulies kuku_at_kukulies.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
On Fri, 13 Jan 2006, Peter Jeremy wrote: PJ> >The process is running now since yesterday evening and it is at 53 MB PJ> >at a transfer rate of about 1.1 MB/s. PJ> > PJ> >In case the the result being unusable I would like to find a way to make this PJ> >copying faster. PJ> PJ> Note that whilst increasing the DD blocksize will speed up the PJ> transfer, it will also increase the amount of collateral damage when a PJ> hard error occurs. If you rummage around the ports or tools tree, PJ> you'll find a utility (its name escapes me but I believe it was PJ> written by phk) that is designed to do disk-to-disk recovery - it PJ> copys data in big slabs until it gets an error and then works around PJ> the faulty area block by block. PJ> PJ> You should also install /usr/ports/sysutils/smartmontools - this PJ> handles S.M.A.R.T. I would suggest also using src/tools/tools/recoverdisk by phk (I still not sure why it's not a port) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
On Thu, Jan 12, 2006 at 02:23:37PM -0700, Kenneth D. Merry wrote: > > written by phk) that is designed to do disk-to-disk recovery - it > > copys data in big slabs until it gets an error and then works around > > the faulty area block by block. > > It's called 'recoverdisk', and is in src/tools/tools/recoverdisk. > > I used it to copy a friend's hard drive, and it worked well. (Although the > supposedly 'bad' disk didn't turn out to have any bad sectors.) > > Ken I was able to recover. The 0.9980 copy of my damaged disk to the identical new one, using recoverdisk /dev/ad2 /dev/ad3 turned out to have been successful. The program was still trying to improve the result but I didn't see any increase of recoverd block, so I terminated it. But the result was a fully functioning bootable (Windows XP) disk. Probably due to the fact that the system (Windows) had been successful in repairing itself by remapping bad clusters of files to intact areas (all partitions were FAT32) the resulting copy was fully functional. I never had really hard disk errors, just the frequent CHKDSK that were required. I believe to recall that Hitach (IBM) had a design error in their Deskstar series when the firmware of the drive did not randomly park the head but left it only at the beginning of the disk all the time resulting in that area preferably being 'worn out' - I have been victim of that bad 40 GB Deskstar series in the past several times. Don't know if this still was the case with the Travelstar mobile computers disks series. The frequent errors I had in hiberfil.sys point into something in that direction (only my little theory). Just for the record: Before I wanted to give back in my faulty disk to my computer supplier as a case for warranty, I zeroed out the faulty disk. dd if=/dev/zero of=/dev/ad2 bs=1m It took half an hour to zero out the 80GB. Transferrate 44 MB/s? And not a single error ? Or is this normal? Then I tried to read back dd if=/dev/ad2 of=/dev/zero bs=2m Yes, just for the fun I said 2m blocksiye. And now we come back to FreeBSD contents: The system froze at this command (FreeBSD 5.2.1 on that machine) -- Chris Christoph P. U. Kukulies kuku_at_kukulies.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
Am 13.01.2006 um 14:29 schrieb Christoph P. Kukulies: Just for the record: Before I wanted to give back in my faulty disk to my computer supplier as a case for warranty, I zeroed out the faulty disk. dd if=/dev/zero of=/dev/ad2 bs=1m It took half an hour to zero out the 80GB. Transferrate 44 MB/s? And not a single error ? Or is this normal? Depending on the model, 44 MB/s seems quite OK. Certainly on the fast side for a 2.5" laptop drive, but not unheard of these days. It is quite possible that the disk controller had a couple of sectors it could not read anymore (and giving I/O errors for them), but was able to reallocate once you wrote to them. I would still ditch the disk, though. Would be interesting to see what the smart reallocated sector count says. Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
On Friday 13 January 2006 08:29 am, Christoph P. Kukulies wrote: > On Thu, Jan 12, 2006 at 02:23:37PM -0700, Kenneth D. Merry wrote: > > > written by phk) that is designed to do disk-to-disk recovery - it > > > copys data in big slabs until it gets an error and then works around > > > the faulty area block by block. > > > > It's called 'recoverdisk', and is in src/tools/tools/recoverdisk. > > > > I used it to copy a friend's hard drive, and it worked well. (Although > > the supposedly 'bad' disk didn't turn out to have any bad sectors.) > > I was able to recover. The 0.9980 copy of my damaged disk to the > identical new one, using > > recoverdisk /dev/ad2 /dev/ad3 > > turned out to have been successful. The program was still trying to > improve the result but I didn't see any increase of recoverd block, so I > terminated it. > > Just for the record: Before I wanted to give back in my faulty disk > to my computer supplier as a case for warranty, I zeroed out the faulty > disk. > > dd if=/dev/zero of=/dev/ad2 bs=1m > > It took half an hour to zero out the 80GB. Transferrate 44 MB/s? > And not a single error ? Or is this normal? > > Then I tried to read back > > dd if=/dev/ad2 of=/dev/zero bs=2m > > Yes, just for the fun I said 2m blocksiye. And now we come back > to FreeBSD contents: > > The system froze at this command (FreeBSD 5.2.1 on that machine) I don't know if this is why the system froze, but /dev/zero is probably not a useful output device. You could use of=/dev/null just to see if the disk reads succeed w/o errors. I've also done "cmp /dev/adX /dev/zero" before, but you don't have any control over how the disk reads are handled that way. JN ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
On Fri, Jan 13, 2006 at 02:29:15PM +0100, Christoph P. Kukulies wrote: > On Thu, Jan 12, 2006 at 02:23:37PM -0700, Kenneth D. Merry wrote: > > Then I tried to read back > > dd if=/dev/ad2 of=/dev/zero bs=2m > > Yes, just for the fun I said 2m blocksiye. And now we come back > to FreeBSD contents: > > The system froze at this command (FreeBSD 5.2.1 on that machine) I believe I posted a followup on this message but probably forgot to do a group reply: It turned out that I first thought it crashed only when I type ^T while the dd was running. But this was accidently happening. Also with bs=1m the system freezes (reproducably). Well, this is some intermediate 5.2.1 so I will give it a try some time again when I have a 6.x running. -- Chris Christoph P. U. Kukulies kuku_at_kukulies.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
