Thanks for the Cc/ping, I appreciate it On Sun, Jul 09, 2017 at 11:38:51AM +0000, Duncan wrote: > At your own risk you can try using btrfs property to set the ro snapshot > to rw. Then you can delete the corrupted files and reset the snapshot > back to ro. > > Of course you'll need to do the same thing on both the send and receive > side in ordered to keep the two reference snapshots in sync. > > However, because my use-case doesn't involve send/receive, I've not been > able to personally verify that the above procedure doesn't screw up an > incremental send/receive job using that modified snapshot as a > reference. There has been one report on the list of someone who did the
On the plus side, on FS #1, I was able to do this, clear all the corrupted blocks and both scrub and btrfs check come back clean. On the 2nd one with more corruption, I'm very saddened to say that I did clear all the blocks, and on my next scrub I got new files that had corruption and didn't show up on the previous scrub (!). So, I rebooted from 4.11 to 4.8 and I'm doing a new scrub will clear all those blocks too, and see if it stays that way, or not. For reference the steps look like this: gargamel:/mnt/btrfs_pool1# btrfs property set Video_ro.20170625_01:23:05 ro false truncate damaged files gargamel:/mnt/btrfs_pool1# btrfs property set Video_ro.20170625_01:23:05 ro true gargamel:/mnt/btrfs_pool1# btrfs scrub start -Bd /mnt/btrfs_pool1 scrub device /dev/mapper/dshelf1 (id 1) done scrub started at Sun Jul 9 08:05:44 2017 and finished after 11:31:58 total bytes scrubbed: 10.43TiB with 0 errors gargamel:/mnt/btrfs_pool1# Thanks, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html