Hi, On 10/02/2018 10:08 PM, Nicholas D Steeves wrote: > 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. This is not a debian specific issue. The upstream btrfs team does not have enough work capacity to do this, and mainly focuses on going forward instead of looking back. And I don't think there's really someone who would know the things mentioned above except for the authors of the patches themselves (who tag them for stable if it's data corruption and if they know it will work (tm)), or the btrfs maintainer who knows which ones to put together in which order to prepare the next kernel release. > 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) For the -o ssd issue, in hindsight, it was a mistake to not get that into 4.9 earlier. Every user who wants to try out btrfs on his/her computer with Stretch and uses it as the root filesystem on a disk which is not too large is still affected by this sub-optimal behaviour. So I guess that's a TODO for me, to still get it done now. It's 951e7966 and 583b723151 with a few small changes to make it apply. At least it has had enough testing, and the amount of users with out-of-space filesystems has decreased notably in the last year in #btrfs IRC. :) Hans
Attachment:
signature.asc
Description: OpenPGP digital signature