On Wed, Oct 03, 2018 at 09:56:13AM +0000, Michael Firth wrote: > > > > 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... > > That is good to know. I will run a "scrub" on the partition soon to check for > any > other issues. I am running on a VM on top of a hardware RAID array of > spinning disks, so hopefully the SSD issue doesn't apply.
To find out: cat /sys/block/your_hardware_raid_block_device/queue/rotational If it returns "0" then you're affected by the -o ssd bug, but if it returns "1" then there is nothing to worry about. :-) While this issue will become obsolete when the fix is backported I'm curious to learn if hardware RAID registers as nonrotational, so please let me know. I suspect it will register as nonrotational, because then the kernel will let the RAID controller merge and reorder IO as it sees fit. > > There was a BTRFS patch in the update that became available an hour after my > crash: > > linux (4.9.110-3+deb9u5) stretch-security; urgency=high > . > . > . > * btrfs: relocation: Only remove reloc rb_trees if reloc control has been > initialized (CVE-2018-14609) > > I'm not sure if that is a Debian specific patch or whether it is a Debian > specific > merge from another version Oh Nice! I'm really happy to see this. Thank you Ben and kernel team! > > I wasn't able to find status of the second one wrt linux-4.9.x. > > Though the description is similar, I don't think patch 972419 is actually > either of > the two patches referenced from that mail. I think I will ask on the BTRFS > mailing > list what the current status of all of these patches is. Thanks. > > 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) > > > I agree with this, and with Hans's comment that because it isn't a Debian > specific > issue it should be handled upstream. I guess the question comes partly from > not > knowing if/how/when upstream V4.9.X kernel changes are merged into the Debian > Stretch kernel. The version number is a hint. Looking at the changelog for the package, you'll see stretch released with 4.9.30-2, was updated with security fixes in 4.9.30-2+deb9u1, was updated from upstream LTS in 4.9.47-1, etc, and is now at 4.9.110-3+deb9u6. Cheers, Nicholas
