At 12/05/2016 03:07 PM, Eryu Guan wrote:
On Tue, Nov 22, 2016 at 04:38:08PM +0800, Qu Wenruo wrote:
Despite the scrub test cases in fstests, there is not even one test case
which really checked if scrub can recover data.
In fact, btrfs scrub for RAID56 will even corrupt correct data stripes.
On Tue, Nov 22, 2016 at 04:38:08PM +0800, Qu Wenruo wrote:
> Despite the scrub test cases in fstests, there is not even one test case
> which really checked if scrub can recover data.
>
> In fact, btrfs scrub for RAID56 will even corrupt correct data stripes.
>
> So let's start from the needed
On Tue, Nov 22, 2016 at 04:38:09PM +0800, Qu Wenruo wrote:
> Rename _require_btrfs() to _require_btrfs_subcommand() to avoid
> confusion, as all other _require_btrfs_* has a quite clear suffix, like
> _require_btrfs_mkfs_feature() or _require_btrfs_fs_feature().
>
> Signed-off-by: Qu Wenruo
Hi, Goldwyn and David,
This patch seems to cause btrfs test case 023 to fail.
Bisect leads me to this patch.
$ ./btrfs check ~/quota_balance_loop_backref.raw.restored
Checking filesystem on /home/adam/quota_balance_loop_backref.raw.restored
UUID: c33c5ce3-3ad9-4320-9201-c337c04e0051
checking
> Maybe -D would list all the file structures?
I tried that first but didn't see anything, but when combined with -v it
shows the files that would have been restored.
e.g.
# btrfs restore -v -D --path-regex '^/(|Documents(|/.*))$'
/dev/mapper/data-0 /tmp
Awesome, big thanks for your help!
subscribe linux-btrfs
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
At 12/05/2016 11:49 AM, Calle Kabo wrote:
IMHO there will be 2 alternative method to recover:
1) Btrfs restore
The safest method to recover files.
Although it may need a lot of space to restore recovered data.
2) Btrfs check --init-extent-tree
This will use fs tree to try to
> IMHO there will be 2 alternative method to recover:
>
> 1) Btrfs restore
>The safest method to recover files.
>Although it may need a lot of space to restore recovered data.
>
> 2) Btrfs check --init-extent-tree
>This will use fs tree to try to rebuild the extent tree.
>I don't
At 12/05/2016 10:28 AM, Calle Kabo wrote:
Hi,
I've got a Netgear NAS with an encrypted 4 disk RAID5 setup. One of the
hard drives was emailing me about errors so I swapped it out before it
died. While syncing another disk died. So I've cloned the disk I
replaced before it died and managed to
Henk Slager posted on Sun, 04 Dec 2016 23:17:23 +0100 as excerpted:
> There are no btrfs changes between kernels 4.8.10 and 4.8.11. There is
> no compress mount option in my case, that is the only thing I currently
> can think of that could make your Set shared number non-zero.
Compression...
Marc Joliet posted on Sun, 04 Dec 2016 20:20:51 +0100 as excerpted:
> On Sunday 04 December 2016 18:24:08 Duncan wrote:
>> Marc Joliet posted on Sun, 04 Dec 2016 17:02:48 +0100 as excerpted:
>> > [After trying it]
>> >
>> > Well, crap, I was able to get images of the file system (one
>> >
Hi,
I've got a Netgear NAS with an encrypted 4 disk RAID5 setup. One of the
hard drives was emailing me about errors so I swapped it out before it
died. While syncing another disk died. So I've cloned the disk I
replaced before it died and managed to get the array running again. You
can read more
At 12/04/2016 02:40 AM, Marc Joliet wrote:
Hello all,
I'm having some trouble with btrfs on a laptop, possibly due to qgroups.
Specifically, some file system activities (e.g., snapshot creation,
baloo_file_extractor from KDE Plasma) cause the system to hang for up to about
40 minutes, maybe
On Sun, Dec 4, 2016 at 3:17 PM, Henk Slager wrote:
> On Sun, Dec 4, 2016 at 7:30 PM, Chris Murphy wrote:
>> Hi,
>>
>> [chris@f25s ~]$ uname -r
>> 4.8.11-300.fc25.x86_64
>> [chris@f25s ~]$ rpm -q btrfs-progs
>> btrfs-progs-4.8.5-1.fc26.x86_64
>>
>>
>>
On 23 November 2016 at 20:58, Dave Jones wrote:
> On Wed, Nov 23, 2016 at 02:34:19PM -0500, Dave Jones wrote:
>
> > [ 317.689216] BUG: Bad page state in process kworker/u8:8 pfn:4d8fd4
> > trace from just before this happened. Does this shed any light ?
> >
> >
On Sun, Dec 4, 2016 at 7:30 PM, Chris Murphy wrote:
> Hi,
>
> [chris@f25s ~]$ uname -r
> 4.8.11-300.fc25.x86_64
> [chris@f25s ~]$ rpm -q btrfs-progs
> btrfs-progs-4.8.5-1.fc26.x86_64
>
>
> I'm not finding any pattern to this so far, but it's definitely not
> always
4.8.11-300.fc25.x86_64
I'm currently doing a btrfs send/receive and I'm seeing a rather large
hit for crc32c, bigger than aes-ni (the volume is on dm crypt), using
perf top.
14.03% btrfs[.] __crc32c_le
10.50% [kernel] [k]
Another example:
[chris@f25s ~]$ sudo btrfs fi du -s /mnt/first/everything-new
Total Exclusive Set shared Filename
367.54GiB14.21GiB 350.95GiB /mnt/first/everything-new
The problem here is that Exclusive + Shared ≠ Total. Rather those two
add up to 365.16GiB, which suggests
On Sun, Dec 04, 2016 at 12:51:53PM +0800, Pan Bian wrote:
> In function btrfs_uuid_tree_iterate(), errno is assigned to variable ret
> on errors. However, it directly returns 0. It may be better to return
> ret. This patch also removes the warning, because the caller already
> prints a warning.
>
On Sunday 04 December 2016 18:24:08 Duncan wrote:
> Marc Joliet posted on Sun, 04 Dec 2016 17:02:48 +0100 as excerpted:
> > That's a good idea, although I'll probably start with sysrescuecd (Linux
> > 4.8.5 and btrfs-progs 4.7.3), as I already have experience with it.
> >
> > [After trying it]
>
Hi all,
I noticed that a monthly differential snapshot creation ended with an
error although the created snapshot itself seemed OK. To test en be
more confident, I also transferred the diff between the 2016-12-01 en
2016-12-02 and that went without an error from send or receive. The
send runs on
On Sun, Dec 4, 2016 at 9:02 AM, Marc Joliet wrote:
>
> Also, now the file system fails with the BUG I mentioned, see here:
>
> [Sun Dec 4 12:27:07 2016] BUG: unable to handle kernel paging request at
> fe10
> [Sun Dec 4 12:27:07 2016] IP: []
>
Hi,
[chris@f25s ~]$ uname -r
4.8.11-300.fc25.x86_64
[chris@f25s ~]$ rpm -q btrfs-progs
btrfs-progs-4.8.5-1.fc26.x86_64
I'm not finding any pattern to this so far, but it's definitely not
always reliable. Here is today's example.
[chris@f25s ~]$ sudo btrfs fi du -s /mnt/second/jackson.2015/
Marc Joliet posted on Sun, 04 Dec 2016 17:02:48 +0100 as excerpted:
> That's a good idea, although I'll probably start with sysrescuecd (Linux
> 4.8.5 and btrfs-progs 4.7.3), as I already have experience with it.
>
> [After trying it]
>
> Well, crap, I was able to get images of the file system
> I haven't seen this with 4.7.10. I suggest running 'btrfs check'
> (without repair) using a recent btrfs-progs. You can find 4.8.3 in
> koji, just download the appropriate rpm, and 'dnf update *rpm'
>
> As for kernel, Fedora 23 has 4.8.8 in updates (stable) and 4.8.10 is
> in updates-testing, I
On Sunday 04 December 2016 03:10:19 Adam Borowski wrote:
> On Sat, Dec 03, 2016 at 10:46:40PM +0100, Marc Joliet wrote:
> > As it's a rescue shell, I have only the one shell AFAIK, and it's occupied
> > by mount. So I can't tell if there are dmesg entries, however, when this
> > happens during a
OK, so I tried a few things, to now avail, more below.
On Saturday 03 December 2016 15:56:45 Chris Murphy wrote:
> On Sat, Dec 3, 2016 at 2:46 PM, Marc Joliet wrote:
> > On Saturday 03 December 2016 13:42:42 Chris Murphy wrote:
> >> On Sat, Dec 3, 2016 at 11:40 AM, Marc Joliet
27 matches
Mail list logo