On 4.05.2018 01:27, Jeff Mahoney wrote:
> On 5/3/18 2:23 AM, Nikolay Borisov wrote:
>>
>>
>> On 3.05.2018 00:11, je...@suse.com wrote:
>>> From: Jeff Mahoney
>>>
>>> Hi Dave -
>>>
>>> Here's the updated patchset for the rescan races. This fixes the issue
>>> where we'd try to start multiple w
Under the following case, qgroup rescan can double account cowed tree
blocks:
In this case, extent tree only has one tree block.
-
| transid=5 last committed=4
| btrfs_qgroup_rescan_worker()
| |- btrfs_start_transaction()
| | transid = 5
| |- qgroup_rescan_leaf()
||- btrfs_search_slot_for_re
On Wed, May 2, 2018 at 7:55 PM Nikolay Borisov wrote:
> Originally commit 2681e00f00fe ("btrfs-progs: check for matchingi
> free space in cache") added the account_super_bytes function to prevent
> false negative when running btrfs check. Turns out this function is
> really copied exclude_super_s
On Wed, May 2, 2018 at 9:15 PM Qu Wenruo wrote:
> On 2018年05月02日 20:49, Nikolay Borisov wrote:
> >
> >
> > On 2.05.2018 15:29, Qu Wenruo wrote:
> >>
> >>
> >> On 2018年05月02日 19:52, Nikolay Borisov wrote:
> >>> Originally commit 2681e00f00fe ("btrfs-progs: check for matchingi
> >>> free space i
Skip testing unnecessary algorithms to speedup module initialization
For my systems:
Before: 1.510s (initrd)
After: 977ms (initrd) # I set prefer to fastest algorithm
Dmesg after patch:
[1.190042] raid6: avx2x4 gen() 28153 MB/s
[1.246683] raid6: avx2x4 xor() 19440 MB/s
[1.24
On 2018年05月04日 00:43, David Sterba wrote:
> On Tue, Dec 19, 2017 at 03:44:54PM +0800, Qu Wenruo wrote:
>> When multiple pending snapshots referring the same source subvolume are
>> executed, enabled quota will cause root item corruption, where root
>> items are using old bytenr (no backref in ext
On 5/3/18 2:23 AM, Nikolay Borisov wrote:
>
>
> On 3.05.2018 00:11, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> Hi Dave -
>>
>> Here's the updated patchset for the rescan races. This fixes the issue
>> where we'd try to start multiple workers. It introduces a new "ready"
>> bool that we
On 08/02/2017 08:47 PM, Chris Mason wrote:
>> I agree, MD pretty much needs a separate device simply because they can't
>> allocate arbitrary space on the other array members. BTRFS can do that
>> though, and I would actually think that that would be _easier_ to implement
>> than having a separ
On 05/03/2018 02:47 PM, Alberto Bursi wrote:
>
>
> On 01/05/2018 23:57, Gandalf Corvotempesta wrote:
>> Hi to all
>> I've found some patches from Andrea Mazzoleni that adds support up to 6
>> parity raid.
>> Why these are wasn't merged ?
>> With modern disk size, having something greater than 2 p
On 05/03/2018 01:26 PM, Austin S. Hemmelgarn wrote:
>> My intention was to highlight that the parity-checksum is not related to the
>> reliability and safety of raid5/6.
> It may not be related to the safety, but it is arguably indirectly related to
> the reliability, dependent on your definition
On Tue, Dec 19, 2017 at 03:44:54PM +0800, Qu Wenruo wrote:
> When multiple pending snapshots referring the same source subvolume are
> executed, enabled quota will cause root item corruption, where root
> items are using old bytenr (no backref in extent tree).
>
> This can be triggered by fstests
On 5/3/18 11:52 AM, Nikolay Borisov wrote:
>
>
> On 3.05.2018 16:39, Jeff Mahoney wrote:
>> On 5/3/18 3:24 AM, Nikolay Borisov wrote:
>>>
>>>
>>> On 3.05.2018 00:11, je...@suse.com wrote:
From: Jeff Mahoney
Commit 8d9eddad194 (Btrfs: fix qgroup rescan worker initialization)
On 3.05.2018 16:39, Jeff Mahoney wrote:
> On 5/3/18 3:24 AM, Nikolay Borisov wrote:
>>
>>
>> On 3.05.2018 00:11, je...@suse.com wrote:
>>> From: Jeff Mahoney
>>>
>>> Commit 8d9eddad194 (Btrfs: fix qgroup rescan worker initialization)
>>> fixed the issue with BTRFS_IOC_QUOTA_RESCAN_WAIT being r
On 5/3/18 3:24 AM, Nikolay Borisov wrote:
>
>
> On 3.05.2018 00:11, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> Commit 8d9eddad194 (Btrfs: fix qgroup rescan worker initialization)
>> fixed the issue with BTRFS_IOC_QUOTA_RESCAN_WAIT being racy, but
>> ended up reintroducing the hang-on-unm
On 01/05/2018 23:57, Gandalf Corvotempesta wrote:
> Hi to all
> I've found some patches from Andrea Mazzoleni that adds support up to 6
> parity raid.
> Why these are wasn't merged ?
> With modern disk size, having something greater than 2 parity, would be
> great.
> --
> To unsubscribe from this
On 2018-05-03 04:11, Andrei Borzenkov wrote:
On Wed, May 2, 2018 at 10:29 PM, Austin S. Hemmelgarn
wrote:
...
Assume you have a BTRFS raid5 volume consisting of 6 8TB disks (which gives
you 40TB of usable space). You're storing roughly 20TB of data on it, using
a 16kB block size, and it sees
On 2018-05-02 16:40, Goffredo Baroncelli wrote:
On 05/02/2018 09:29 PM, Austin S. Hemmelgarn wrote:
On 2018-05-02 13:25, Goffredo Baroncelli wrote:
On 05/02/2018 06:55 PM, waxhead wrote:
So again, which problem would solve having the parity checksummed ? On the best
of my knowledge nothing.
On 3.05.2018 11:07, Anand Jain wrote:
>
>
> On 04/19/2018 03:25 PM, Nikolay Borisov wrote:
>>
>>
>> On 19.04.2018 08:32, Fengguang Wu wrote:
>>> Hello,
>>>
>>> FYI this happens in mainline kernel and at least dates back to v4.16 .
>>>
>>> It's rather rare error and happens when running xfstest
On Wed, May 2, 2018 at 10:29 PM, Austin S. Hemmelgarn
wrote:
...
>
> Assume you have a BTRFS raid5 volume consisting of 6 8TB disks (which gives
> you 40TB of usable space). You're storing roughly 20TB of data on it, using
> a 16kB block size, and it sees about 1GB of writes a day, with no partia
On 04/19/2018 03:25 PM, Nikolay Borisov wrote:
On 19.04.2018 08:32, Fengguang Wu wrote:
Hello,
FYI this happens in mainline kernel and at least dates back to v4.16 .
It's rather rare error and happens when running xfstests.
Yeah, so this is something which only recently was characterised
On 3.05.2018 00:11, je...@suse.com wrote:
> From: Jeff Mahoney
>
> Commit 8d9eddad194 (Btrfs: fix qgroup rescan worker initialization)
> fixed the issue with BTRFS_IOC_QUOTA_RESCAN_WAIT being racy, but
> ended up reintroducing the hang-on-unmount bug that the commit it
> intended to fix addres
When doing qgroup rescan using the following script (modified from
btrfs/017 test case), we can sometimes hit qgroup corruption.
--
umount $dev &> /dev/null
umount $mnt &> /dev/null
mkfs.btrfs -f -n 64k $dev
mount $dev $mnt
extent_size=8192
xfs_io -f -d -c "pwrite 0 $extent_size" $mnt/foo >
Hi!
I'm running btrfs on a bcache device, for now, it performed flawlessly.
Yesterday, however, during backup, I found the following errors in the
journal:
BTRFS critical (device bcache0): corrupt leaf: root=1 block=367591424
slot=1 ino=10085264, name hash mismatch with key, have
0x
23 matches
Mail list logo