On Mon, 2017-01-16 at 11:16 +0800, Qu Wenruo wrote: > It would be very nice if you could paste the output of > "btrfs-debug-tree -t extent <your_device>" and "btrfs-debug-tree -t > root > <your device>" > > That would help us to fix the bug in lowmem mode. I'll send you the link in a private mail ... if any other developer needs it, just ask me or Qu for the link.
> BTW, if it's possible, would you please try to run btrfs-check > before > your next deletion on ro-snapshots? You mean in general, when I do my next runs of backups respectively snaphot-cleanup? Sure, actually I did this this time as well (in original mode, though), and no error was found. For what should I look out? > Not really needed, as all corruption happens on tree block of root > 6403, > it means, if it's a real corruption, it will only disturb you(make > fs > suddenly RO) when you try to modify something(leaves under that node) > in > that subvolume. Ah... and it couldn't cause corruption to the same data blocks if they were used by another snaphshot? > And I highly suspect if the subvolume 6403 is the RO snapshot you > just removed. I guess there is no way to find out whether it was that snapshot, is there? > If 'btrfs subvolume list' can't find that subvolume, then I think > it's > mostly OK for you to RW mount and wait the subvolume to be fully > deleted. > > And I think you have already provided enough data for us to, at > least > try to, reproduce the bug. I won't do the remount,rw this night, so you have the rest of your day/night time to think of anything further I should test or provide you with from that fs... then it will be "gone" (in the sense of mounted RW). Just give your veto if I should wait :) Thanks, Chris.
smime.p7s
Description: S/MIME cryptographic signature
