Re: corruption: yet another one after deleting a ro snapshot

On Wed, 2017-01-18 at 08:41 +0800, Qu Wenruo wrote: > Since we have your extent tree and root tree dump, I think we should > be  > able to build a image to reproduce the case. +1 > BTW, your fs is too large for us to really do some verification or > other  > work. Sure I know... but that's

Re: corruption: yet another one after deleting a ro snapshot

At 01/17/2017 06:39 PM, Christoph Anton Mitterer wrote: Am 17. Januar 2017 09:53:19 MEZ schrieb Qu Wenruo : Just lowmem false alert, as extent-tree dump shows complete fine result. I'll CC you and adds your reported-by tag when there is any update on this case.

Re: corruption: yet another one after deleting a ro snapshot

Am 17. Januar 2017 09:53:19 MEZ schrieb Qu Wenruo : >Just lowmem false alert, as extent-tree dump shows complete fine >result. > >I'll CC you and adds your reported-by tag when there is any update on >this case. Fine, just one thing left right more from my side on this

Re: corruption: yet another one after deleting a ro snapshot

At 01/17/2017 06:07 AM, Christoph Anton Mitterer wrote: On Mon, 2017-01-16 at 13:47 +0800, Qu Wenruo wrote: 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? "btrfs subvolume list"

Re: corruption: yet another one after deleting a ro snapshot

On Mon, 2017-01-16 at 13:47 +0800, Qu Wenruo wrote: > > > 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? > > "btrfs subvolume list" could do it." Well that was

Re: corruption: yet another one after deleting a ro snapshot

Hi. If it can be helpful. How to double checking the status of my filesystem, I launched ' btrfs scrub / ' and/or ' du -sh /* '. If the file system is corrupt, in my case, the command have aborted. Regards. gdb -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the

Re: corruption: yet another one after deleting a ro snapshot

At 01/16/2017 12:53 PM, Christoph Anton Mitterer wrote: 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 " and "btrfs-debug-tree -t root " That would help us to fix the bug in lowmem mode. I'll send you

Re: corruption: yet another one after deleting a ro snapshot

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 " and "btrfs-debug-tree -t > root  > " > > That would help us to fix the bug in lowmem mode. I'll send you the link in a private mail ... if any other

Re: corruption: yet another one after deleting a ro snapshot

At 01/16/2017 10:56 AM, Christoph Anton Mitterer wrote: On Mon, 2017-01-16 at 09:38 +0800, Qu Wenruo wrote: So the fs is REALLY corrupted. *sigh* ... (not as in fuck-I'm-loosing-my-data™ ... but as in *sigh* another-possibly-deeply-hidden-bug-in-btrfs-that-might-eventually-

Re: corruption: yet another one after deleting a ro snapshot

On Mon, 2017-01-16 at 09:38 +0800, Qu Wenruo wrote: > So the fs is REALLY corrupted. *sigh* ... (not as in fuck-I'm-loosing-my-data™ ... but as in *sigh* another-possibly-deeply-hidden-bug-in-btrfs-that-might-eventually- cause-data-loss...) > BTW, lowmem mode seems to have a new false alert when

Re: corruption: yet another one after deleting a ro snapshot

At 01/16/2017 01:04 AM, Christoph Anton Mitterer wrote: On Thu, 2017-01-12 at 10:38 +0800, Qu Wenruo wrote: IIRC, RO mount won't continue background deletion. I see. Would you please try 4.9 btrfs-progs? Done now, see results (lowmem and original mode) below: # btrfs version

Re: corruption: yet another one after deleting a ro snapshot

On Thu, 2017-01-12 at 10:38 +0800, Qu Wenruo wrote: > IIRC, RO mount won't continue background deletion. I see. > Would you please try 4.9 btrfs-progs? Done now, see results (lowmem and original mode) below: # btrfs version btrfs-progs v4.9 # btrfs check /dev/nbd0 ; echo $? Checking

Re: corruption: yet another one after deleting a ro snapshot

Hi. I had issues with a case very similar to yours. My experience is that subvolume delete and/or attempt to repair the file system makes the situation worse. To gain experience and accepting losing the data of the file system, I have always tried to recover the file system. But then I always

Re: corruption: yet another one after deleting a ro snapshot

At 01/12/2017 10:28 AM, Christoph Anton Mitterer wrote: Hey Qu, On Thu, 2017-01-12 at 09:25 +0800, Qu Wenruo wrote: And since you just deleted a subvolume and unmount it soon Indeed, I unmounted it pretty quickly afterwards... I had mounted it (ro) in the meantime, and did a whole find

Re: corruption: yet another one after deleting a ro snapshot

Hey Qu, On Thu, 2017-01-12 at 09:25 +0800, Qu Wenruo wrote: > And since you just deleted a subvolume and unmount it soon Indeed, I unmounted it pretty quickly afterwards... I had mounted it (ro) in the meantime, and did a whole find mntoint > /dev/null on it just to see whether going through the

Re: corruption: yet another one after deleting a ro snapshot

At 01/12/2017 09:07 AM, Christoph Anton Mitterer wrote: Hey. Linux heisenberg 4.8.0-2-amd64 #1 SMP Debian 4.8.15-2 (2017-01-04) x86_64 GNU/Linux btrfs-progs v4.7.3 I've had this already at least once some year ago or so: I was doing backups (incremental via send/receive). After everything

Re: corruption: yet another one after deleting a ro snapshot

Oops forgot to copy and past the actual fsck output O:-) # btrfs check /dev/mapper/data-a3 ; echo $? Checking filesystem on /dev/mapper/data-a3 UUID: 326d292d-f97b-43ca-b1e8-c722d3474719 checking extents ref mismatch on [37765120 16384] extent item 0, found 1 Backref 37765120 parent 6403 root