On Mon, Aug 03, 2015 at 11:05:46AM -0400, Sonic wrote:
On Mon, Aug 3, 2015 at 10:43 AM, Sonic sonicsm...@gmail.com wrote:
Is btrfs rescue super-recover safe to run? IOW, will it ask before
doing anything possibly destructive (assuming I don't give it a -y)?
Seemed a bit safe so I went for
On Mon, Aug 3, 2015 at 1:17 AM, Duncan 1i5t5.dun...@cox.net wrote:
The first thing you need to do in terms of trying to recover, is restore
the superblock on the damaged device. Since btrfs keeps multiple copies
(up to three, once the filesystem is large enough, as yours is) per
device,
On Mon, Aug 3, 2015 at 11:28 AM, Hugo Mills h...@carfax.org.uk wrote:
Very unlikely and definitely not, respectively. There's nothing at
all here to indicate that you've got a broken log, so dropping it
would be at best pointless. The chunk tree is also most likely
undamaged on both copies.
Also tried:
mount -o recovery,ro /mnt/butter/
And dmesg gives:
[88228.756622] BTRFS info (device sde): enabling auto recovery
[88228.756635] BTRFS info (device sde): disk space caching is enabled
[88228.757244] BTRFS (device sde): bad tree block start
8330001001141004672 20971520
[88228.757248]
Output of btrfs check:
btrfs check /dev/sdc
warning, device 2 is missing
bytenr mismatch, want=20971520, have=0
Couldn't read chunk root
Couldn't open file system
btrfs check /dev/sde
checksum verify failed on 20971520 found 8B1D9672 wanted 2F8A4238
checksum verify failed on 20971520 found
On Mon, Aug 3, 2015 at 12:32 PM, Sonic sonicsm...@gmail.com wrote:
btrfs rescue chunk-recover
Ran this:
btrfs rescue chunk-recover -v /dev/sde |tee brcr.txt
Got this (very end of output):
==
Unrecoverable Chunks:
Total Chunks: 3292
Recoverable:
John Ettedgui wrote on 2015/07/31 21:35 -0700:
On Thu, Jul 30, 2015 at 10:45 PM, John Ettedgui john.etted...@gmail.com wrote:
On Thu, Jul 30, 2015 at 10:40 PM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
It seems that you're using Chromium while doing the dump. :)
If no CD drive, I'll
On Mon, Aug 3, 2015 at 6:55 PM, John Ettedgui john.etted...@gmail.com wrote:
On Mon, Aug 3, 2015 at 6:39 PM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
Oh, you were using trace-cmd, that's why the data is so huge.
Oh, I thought it was just automating the work for me, but without any
sort of
On Mon, Aug 3, 2015 at 6:39 PM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
Oh, you were using trace-cmd, that's why the data is so huge.
Oh, I thought it was just automating the work for me, but without any
sort of impact.
I was originally hoping you just copy the trace file, which is human
Out of frustration and vodka I tried:
btrfs check --repair /dev/sde
To instantly be met with:
enabling repair mode
checksum verify failed on 20971520 found 8B1D9672 wanted 2F8A4238
checksum verify failed on 20971520 found 8B1D9672 wanted 2F8A4238
bytenr mismatch, want=20971520,
On Mon, Aug 3, 2015 at 8:01 PM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
Oh, converted...
That's too bad. :(
[[What's wrong with convert]]
Although btrfs is flex enough in theory to fit itself into the free space of
ext* and works fine,
But in practice, ext* is too fragmental in the
Add extra explaination on btrfs qgroup on the following two things:
1) Need sync to show accurate qgroup numbers
2) Cow may cause extra quota usage
Although btrfs qgroup is still buggy, especially for limit behavior, but
some strange behavior is not really a bug.
Just add these explaination for
John Ettedgui wrote on 2015/08/03 18:55 -0700:
On Mon, Aug 3, 2015 at 6:39 PM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
Oh, you were using trace-cmd, that's why the data is so huge.
Oh, I thought it was just automating the work for me, but without any
sort of impact.
I was originally
Sonic posted on Mon, 03 Aug 2015 22:20:38 -0400 as excerpted:
I'm thinking this is a lost cause. Also thinking I need to provide for
some redundancy in the future :-)
Any other suggestions before I give up the ghost on this?
I don't remember you saying anything about trying btrfs restore.
On Mon, Aug 3, 2015 at 4:22 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
Yes, you're right, that's a dead loop.
But for better debugging, would you please upload the following info?
1) output of command btrfs-debug-tree -t 5 DEV.
The only important things are info about that inode.
Whose
David Sterba wrote on 2015/07/28 16:50 +0200:
On Tue, Jul 28, 2015 at 04:30:36PM +0800, Qu Wenruo wrote:
Although Liu Bo has already submitted a V10 version of his deduplication
implement, here is another implement for it.
What's the reason to start another implementation?
[[CORE
On Sun, Aug 02, 2015 at 11:42:25PM -0600, Chris Murphy wrote:
I can't tell what the data and metadata profile are? That it won't
mount degraded makes me think the metadata is not explicitly raid1;
and it either raid0 or accidentally single or dup which can happen at
mkfs time on single device,
During the change to new btrfs extent-oriented qgroup implement, due to
it doesn't use the old __qgroup_excl_accounting() for exclusive extent,
it didn't free the reserved bytes.
The bug will cause limit function go crazy as the reserved space is
never freed, increasing limit will have no effect
On Sat, Aug 01, 2015 at 02:48:41PM -0600, Chris Murphy wrote:
On Sat, Aug 1, 2015 at 2:42 PM, Hugo Mills h...@carfax.org.uk wrote:
On Sat, Aug 01, 2015 at 11:29:40AM -0600, Chris Murphy wrote:
Does someone with wiki edit capability want to put up a warning about
btrfs-convert problems? I
On Mon, Aug 3, 2015 at 12:09 PM, Alex alexinbeij...@gmail.com wrote:
20:03 ~ % uname -a
Linux alex-ThinkPad-L530 4.1.0-rc3+ #2 SMP Sun Jul 5 22:24:05 CAT 2015
x86_64 x86_64 x86_64 GNU/Linux
4.1.0 is not mainline anymore, so I don't see a mid release candidate
of it being relevant because
Are either one of these called for?
btrfs check --repair
or
btrfs check --repair --init-csum-tree
Seems like they might be a last ditch attempt. Is one preferred over the other?
Is:
btrfs rescue chunk-recover
a much less dangerous attempt (IOW it wont hurt to try it first)?
Thanks,
Chris
On
Dear Btrfs devs,
I have an external HD formatted with btrfs, and have noticed that
various operations (copying files, deleting files, etc) hang from time
to time. Here's debug output from the latest hang:
dmesg output:
[496960.834080] i915 :00:02.0: BAR 6: [???
Sonic posted on Mon, 03 Aug 2015 12:32:21 -0400 as excerpted:
Are either one of these called for?
btrfs check --repair or btrfs check --repair --init-csum-tree
Seems like they might be a last ditch attempt. Is one preferred over the
other?
The read-only check (without --repair) couldn't
23 matches
Mail list logo
