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 simply
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.
Fine, just one thing left rig
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 issue:
Do you want me to le
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" cou
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 clear,
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
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 the
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 develope
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-
cause-data-loss...
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 c
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
btrfs-progs
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 filesystem
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 h
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 mnto
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
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 wa
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 6
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 was copied, I unmounted the destination fs, made a
fsck, all f
18 matches
Mail list logo