Hi Michael, On Tue, Oct 02, 2018 at 11:37:45AM +0100, Michael Firth wrote: > > After this, there was a file that was errored on the filesystem (as > reported by 'btrfs check'), and it seems BTRFS doesn't have any tools to > resolve the error. Deleting the file at the reported inode has cleared > the error from 'btrfs check', but I am not 100% sure that will have > fixed all the corruption. > As far as I know, if 'btrfs check' is clean then you're in the clear for any known issues involving the fs structure. Of course, a 'btrfs scrub' is necessary to check for data and metadata corruption... BTW, if you're using an ssd, make sure you're mounting with -o nossd, because as far as I know linux-4.9.x still hasn't been patched. P.S. that requires a full rebalance to take effect. Make up-to-date backups before running that rebalance... > This issue looks very like the bug described at: > > https://www.spinics.net/lists/linux-btrfs/msg60984.html > > And in bug report #708509 for a much older kernel (from 2013) > > According to the BTRFS mailing list post above, there are patches > submitted to fix this issue (or one with the same symptoms). > Is there any way to easily determine if these patches are in the Debian > version of the V4.9.110 kernel? The last time I checked I couldn't find any btrfs-specific ones in Debian; I used apt-get source and expected to find a quilt series. > If not, what is the route to get these patches incorporated? Do I need > to talk to the BTRFS people about getting the patches in to the stock > V4.9 kernel, or is this something that the Debian team would apply > directly? The first of the two patches from that 29 Nov 2016 linux-btrfs email appears to be queued for linux-4.9.119: https://lore.kernel.org/patchwork/patch/972419/ I wasn't able to find status of the second one wrt linux-4.9.x. > Kernel bug report output included below, in case it is useful. > > BTRFS may not be a filesystem that everyone uses, but I feel if it is in > the Debian kernel then bugs that can cause data loss should be fixed if > a patch already exists. In principle I agree; although I think it would be safer to coordinate with Greg Kroah-Harman about getting them applied upstream before importing them into Debian, since (afaik) we don't have any btrfs specialists working on our kernel...people who would know if importing one of these patches will introduce unintended side-effects or a rabbit hole of patches. Maybe it would be safer to look at the delta between btrfs in 4.9.x and 4.14.x and ask for backported fixes from 4.14.x to 4.9.x? (eg: more than six months of testing in 4.14.x, like the -o ssd bug that is still present in 4.9.x) Cheers, Nicholas
Attachment:
signature.asc
Description: PGP signature