On 2017-06-07 20:04, Adam Borowski wrote: > On Wed, Jun 07, 2017 at 07:01:21PM +0200, Goffredo Baroncelli wrote: >> On 2017-06-07 17:58, Chris Murphy wrote: >>> 3. My take on this would have been to use btrfs restore and go after >>> the file path if I absolutely needed a copy of this file (no backup), >>> and then copied that back to the file system. >> >> 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. It would need an ioctl to read the file content without the checksum check... > > Thus, it'd have to be a special command or a special argument. > > > Meow! > -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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
