Re: getting rid of "csum failed" on a hw raid

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 07, 2017 at 10:20:53PM +0200, Goffredo Baroncelli wrote:
> On 2017-06-07 20:04, Adam Borowski wrote:
> > On Wed, Jun 07, 2017 at 07:01:21PM +0200, Goffredo Baroncelli wrote:
> >> It might be useful to have a command to handle these situations: read all
> >> the good data, read even the wrong data logging the range were the
> >> checksum is incorrect.  The fact that you have problem in few bytes,
> >> doesn't mean that all the 4k sector has to be discarded.
> > 
> > This is what we did in the DOS times: even when the OS would fail, reading
> > via INT 13h did usually report an error but the memory you gave as the
> > target buffer would have all the data with just one or a few bits flipped --
> > or at worst, when a sector's header was hit, 512 bytes missing.
> > 
> > But that's not a good idea for regular read(), even for root: it's possible
> > the data is not yours and contains some sensitive info from an unrelated
> > file.
> 
> Depends: if the corrupted data are metadata, you are right.  But the
> biggest part of the disk is occupied by data; so the likelihood that the
> corruption is in the data is greater.

Metadata also happens to be rewritten and manipulated more, thus it has a
relatively bigger chance to get mangled.  Corruption at rest is less likely
than corruption in memory or during transfer, and memory is not checksummed.

Two scenarios:
* mangled metadata points to a block belonging to pre-existing unrelated
  data (or secret metadata)
* a new write by mistake overwrites an innocent block of data

Both of these will correctly be caught by checksums, so there's no
information leak.  But there will be if you take that data anyway.  And you
don't manually read every file you managed to restore.

> It would need an ioctl to read the file content without the checksum
> check...

Do modern disks still send the partial data if they determine it to be
corrupt?  If so, every disk-backed filesystem, not just btrfs, could benefit
from such an ioctl.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A tit a day keeps the vet away.
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ (Rejoice as my small-animal-murder-machine got unbroken after
⠈⠳⣄⠀⠀⠀⠀ nearly two years of no catch!)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux