Re: disk non-destructive bad-block write/fix?

On 20 September 2022 3:45:55 pm AEST, grarpamp <grarpamp@gmail.com> wrote:
 > > throwing a lot of errors
 > 
 > USB... reseat cables.

Or try another one/s, if external.

But first I'd skip to your last point ie read testing, which also could catch a bad cable.  If it's just or mainly that, much angst relieved.

 > > Is there a way to exercise the free blocks on a ufs disk and move
 > all
 > > defective ones to the bad-block list?
 > 
 > That's function of the hw, not the fs.

Unless the disk is really ancient, ISTR badblocks(ono) from 2.6-REL days.

 > If you want to nuke the fs and do that to the disk
 > dd if=/dev/urandom of=/dev/da0 bs=1m
 > 
 > If not, then you can pray to hit most of the fs data areas with
 > dd if=/dev/urandom of=/mnt/bigrandfile bs=1m
 > 
 > but that's a prayer.

And closer to last resort ...

 > Better to buy enough media to have backups of backups.

Ack, and it's so cheap these days.

 > > Or is that already happening in the above scenario?
 > 
 > Yes most firmwares modepages are set to automatically
 > write-reallocate, you can fiddle those using the scsi/ata/usb
 > spec and camcontrol.
 > 
 > Store a sha256 of all the files,
 > read them back to verify and compare to that.
 > 
 > > The disk is about 40% full
 > 
 > There's probably not a shrinkfs, and without checking where those
 > existing extents are, attempting to create a tailing 60% fs to
 > move the 40% into to write-realloc it... could end up footshot.

Again, be sure cables are good before such desperate measures.

 > > wondering if the whole rest of it is trashed
 > 
 > dd if=/dev/da0 of=/dev/null bs=1m conv=noerror
 > 
 > But that's only a read test, not a write test.

But nice and safe, for starters - and with noerror reporting all bad bits.

cheers, Ian