On 2019/10/21 下午9:02, Christian Pernegger wrote: > [Please CC me, I'm not on the list.] > > Am Mo., 21. Okt. 2019 um 13:47 Uhr schrieb Austin S. Hemmelgarn > <ahferroin7@xxxxxxxxx>: >> I've [worked with fs clones] like this dozens of times on single-device volumes with exactly zero issues. > > Thank you, I have taken precautions, but it does seem to work fine. > >> There are actually two possible ways I can think of a buggy GPU driver causing this type of issue: [snip] > > Interesting and plausible, but ... > >> Your best option for mitigation [...] is to ensure that your hardware has an IOMMU [...] and ensure it's enabled in firmware. > > It has and it is. (The machine's been specced so GPU pass-through is > an option, should it be required. I haven't gotten around to setting > that up yet, haven't even gotten a second GPU, but I have laid the > groundwork, the IOMMU is enabled and, as far as one can tell from logs > and such, working.) > >> However, there's also the possibility that you may have hardware issues. > > Don't I know it ... The problem is, if there are hardware issues, > that's the first I've seen of them, and while I didn't run torture > tests, there was quite a lot of benchmarking when it was new. Needle > in a haystack. Some memory testing can't hurt, I suppose. Any other > ideas (for hardware testing)? > > Back on the topic of TRIM: I'm 99 % certain discard wasn't set on the > mount (not by me, in any case), but I think Mint runs fstrim > periodically by default. Oh, that explains why only one root (the current generation one) is not all zero. Then it should be a false alert, just fstrim wiped some old tree blocks. But maybe it's some unfortunate race, that fstrim trimmed some tree blocks still in use. This means, it's a bug of btrfs. However I can't find a bug fix during v5.0..v5.3 related to trim. (Only some v5.2 regression and its fixes) So it may be a hidden bug. > Just to be sure, should any form of TRIM be > disabled? Not exactly. There are some thing that is completely safe to trim, the unallocated space. And there may be something tricky to trim, tree blocks. (the bug you hit) One good compromise is, only trim unallocated space. Then you need to pass something parameter for fstrim. Like -o 0 -l 1M. Newer kernel would try to trim block groups in that range, and modern btrfs has no block groups in that range, then fstrim will go trim all unallocated space them. So with that options, fstrim should be safe. BTW, as you can found already, trimmed blocks can make recovery trickier, as old tree blocks are just trimmed, no way to rely on trimmed data. > The only other idea I've got is Timeshift's hourly snapshots. (How) > would btrfs deal with a crash during snapshot creation? In theory, btrfs has transaction and tree block CoW to take care of everything. So no matter when the crash happens, it should be safe. But in real world, you know life is always hard... > > > In other news, I've still not quite given up, mainly because the fs > doesn't look all that broken. The output of btrfs inspect-internal > dump-tree (incl. options), for instance, looks like gibberish to me of > course, but it looks sane, doesn't spew warnings, doesn't error out or > crash. Also plain btrfs check --init-extent-tree errored out, same > with -s0, but with -s1 it's now chugging along. (BTW, is there a > hierarchy among the super block slots, a best or newest one?) As your corruption is only in extent tree. With my patchset, you should be able to mount it, so it's not that screwed up. But extent tree update is really somehow trickier than I thought. Thanks, Qu > > Will keep you posted. > > Cheers, > C. >
Attachment:
signature.asc
Description: OpenPGP digital signature
