Re: How to repair a BTRFS block?

[Duncan <1i5t5.duncan@cox.net>]

Martin Monperrus posted on Fri, 24 Apr 2015 19:44:47 +0200 as excerpted:

> Hi Duncan,
> 
>> The kernel log (dmesg, also logged to syslog/journald on most systems)
>> from during the scrub should capture more information on those errors.
> Thanks. The dmesg log indeed contains the file path (see below).
> 
> The error is in /home/martin/XXXXX. It is related to a low-level error
> ("failed command: READ DMA").
> 
> Beyond this corrupted file, is my disk dead?
> Can I repair the file system or re-create a new one on the same disk?

A direct answer is beyond my knowledge level, certainly without SMART 
status information, etc.  What I do know is that assuming the rest of the 
device is responding fine, most drives keep a number of reserved sectors 
available and will automatically substitute them in on a *write* to an 
affected dead sector.

So if the device in general appears to be working fine, and assuming the 
SMART status still passes, I'd backup everything else on that partition, 
unmount it, then do something like a badblocks destructive write (-w) 
test to the partition.  If it comes back clean, I'd consider the device 
usable again.

Also note that if you run smartctl -A (attributes) on the device before 
attempting anything else and check the raw value for ID 5 (reallocated 
sector count), then check again after doing something like that badblocks 
-w, you can see if it actually relocated any sectors.  Finally, note that 
while it's possible to have a one-off, once a drive starts reallocating 
sectors it often fails relatively quickly as that can indicate a failing 
media layer and once it starts to go, often it doesn't stop.  So once you 
see that value move from zero, do keep an eye on it and if you notice the 
value starting to climb, get the data off that thing as soon as possible.

And of course it should go without saying, but I'll repeat the sysadmin's 
data value rule of thumb anyway, for the benefit of others reading as 
well.  If you care about the data, by definition, you have a (tested) 
backup (a corollary rule states that an untested backup isn't a backup at 
all).  If you don't have a backup, by definition you do NOT care about 
that data, /regardless/ of any claims to the contrary.  Unfortunately, 
many (most?) people end up learning this the hard way, finding out too 
late how much more value the data had than they thought, and thus that 
they /should/ have cared about it more (more backups, more testing of 
them) than they did.

(For those who end up in that situation...)  On the flip side there's the 
big picture.  During hurricane Katrina a data hosting firm in New Orleans 
made (tech) headlines by blogging live their struggle to stay powered and 
online.  I was one of thousands watching that, along with the mainstream 
news about the flooding, looting and dying going on.  Obviously losing a 
bit of data ends up pretty far down the list when you're wet and cold and 
just lost your house and possibly members of your family!  A bit of data 
loss might hurt a bit, but in the big picture, if you're still healthy, 
and have a job and a home and family, it's /not/ the end of the world.  A 
bit of perspective helps! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman