On 2019/7/9 上午8:49, Jungyeon Yoon wrote:
> Hi btrfs developers,
>
> I'm Jungyeon Yoon. I have reported btrfs bug before.
> Some of them have marked to fixed thanks to your efforts.
> Additionally following bugs seems also fixed as I've checked.
> If okay, I would like to close following bugs, to
Hi btrfs developers,
I'm Jungyeon Yoon. I have reported btrfs bug before.
Some of them have marked to fixed thanks to your efforts.
Additionally following bugs seems also fixed as I've checked.
If okay, I would like to close following bugs, too.
https://bugzilla.kernel.org/show_bug.cgi?id=202839
From: Stanislaw Gruszka
Upstream commit 38e3eebff643 ("btrfs: honor path->skip_locking in
backref code") was incorrectly backported to 4.14.y . It misses removal
of two lines from original commit, what cause deadlock.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203993
Reported-by: Oliv
On Mon, Jul 08, 2019 at 02:01:34PM +0200, Stanislaw Gruszka wrote:
> Upstream commit 38e3eebff643 ("btrfs: honor path->skip_locking in
> backref code") was incorrectly backported to 4.14.y . It misses removal
> of two lines from original commit, what cause deadlock.
>
> Bugzilla: https://bugzilla.
On 8.07.19 г. 15:01 ч., Stanislaw Gruszka wrote:
> Upstream commit 38e3eebff643 ("btrfs: honor path->skip_locking in
> backref code") was incorrectly backported to 4.14.y . It misses removal
> of two lines from original commit, what cause deadlock.
>
> Bugzilla: https://bugzilla.kernel.org/show
With CONFIG_BTRFS_FS=y and CONFIG_CRYPTO_CRC32C=m, we get:
fs/btrfs/super.o: In function `btrfs_mount_root':
fs/btrfs/super.c:1557: undefined reference to `crc32c_impl'
fs/btrfs/super.o: In function `btrfs_print_mod_info':
fs/btrfs/super.c:2348: undefined reference to `crc32c_impl'
fs/btrfs/extent
This is already queued:
https://lore.kernel.org/linux-btrfs/20190704161949.gz20...@twin.jikos.cz/T/#t
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Fe
On 2019/7/8 下午9:07, Nikolay Borisov wrote:
>
>
> On 8.07.19 г. 15:50 ч., Qu Wenruo wrote:
>>
>>
>> On 2019/7/8 下午6:43, Nikolay Borisov wrote:
>>>
>>>
>>> On 8.07.19 г. 10:33 ч., Qu Wenruo wrote:
In write_one_cache_group() we always do COW to update BLOCK_GROUP_ITEM.
However under a lot
On 8.07.19 г. 15:50 ч., Qu Wenruo wrote:
>
>
> On 2019/7/8 下午6:43, Nikolay Borisov wrote:
>>
>>
>> On 8.07.19 г. 10:33 ч., Qu Wenruo wrote:
>>> In write_one_cache_group() we always do COW to update BLOCK_GROUP_ITEM.
>>> However under a lot of cases, the cache->item is not changed at all.
>>>
>
While part of btrfs now uses the crypto shash interfaces
for crc32c, we still get a build time dependency in other
places:
fs/btrfs/super.o: In function `btrfs_mount_root':
super.c:(.text+0xc0d4): undefined reference to `crc32c_impl'
fs/btrfs/super.o: In function `btrfs_print_mod_info':
super.c:(.
On 2019/7/8 下午6:43, Nikolay Borisov wrote:
>
>
> On 8.07.19 г. 10:33 ч., Qu Wenruo wrote:
>> In write_one_cache_group() we always do COW to update BLOCK_GROUP_ITEM.
>> However under a lot of cases, the cache->item is not changed at all.
>>
>> E.g:
>> Transaction 123, block group [1M, 1M + 16M)
>
Looks good,
Reviewed-by: Johannes Thumshirn
Thanks Arnd
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21
On Mon, Jul 8, 2019 at 3:02 PM Ulli Horlacher
wrote:
...
>
> root@trulla:/# btrfs subvolume get-default /
> ID 453 gen 2273956 top level 270 path @/.snapshots/128/snapshot
>
> root@trulla:/# btrfs subvolume show / | grep UUID
> UUID: c85dc50a-b126-1441-bddd-2832afac58d2
>
btrfsic_process_written_block() cals btrfsic_process_metablock(),
which has a fairly large stack usage due to the btrfsic_stack_frame
variable. It also calls btrfsic_test_for_metadata(), which now
needs several hundreds of bytes for its SHASH_DESC_ON_STACK().
In some configurations, we end up with
Upstream commit 38e3eebff643 ("btrfs: honor path->skip_locking in
backref code") was incorrectly backported to 4.14.y . It misses removal
of two lines from original commit, what cause deadlock.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203993
Reported-by: Olivier Mazouffre
Fixes: d819
On 8.07.19 г. 10:33 ч., Qu Wenruo wrote:
> [BUG]
> Btrfs-progs sometimes fails to find certain extent backref when
> committing transaction.
> The most reliable way to reproduce it is fsck-test/013 on 64K page sized
> system:
> [...]
> adding new data backref on 315859712 root 287 owner 292
On 8.07.19 г. 10:33 ч., Qu Wenruo wrote:
> In write_one_cache_group() we always do COW to update BLOCK_GROUP_ITEM.
> However under a lot of cases, the cache->item is not changed at all.
>
> E.g:
> Transaction 123, block group [1M, 1M + 16M)
>
> tree block 1M + 0 get freed
> tree block 1M + 16K
I am still trying to understand the default / btrfs setup on SUSE:
root@trulla:/# lsb_release -d
Description:SUSE Linux Enterprise Server 12 SP3
root@trulla:/# btrfs subvolume list -uq /
ID 257 gen 2273953 top level 5 parent_uuid - uuid
294f484f-7ac6-ac4d-8b8b-953b377a3880 path @
ID 258 ge
In write_one_cache_group() we always do COW to update BLOCK_GROUP_ITEM.
However under a lot of cases, the cache->item is not changed at all.
E.g:
Transaction 123, block group [1M, 1M + 16M)
tree block 1M + 0 get freed
tree block 1M + 16K get allocated.
Transaction 123 get committed.
In this cas
[BUG]
Btrfs-progs sometimes fails to find certain extent backref when
committing transaction.
The most reliable way to reproduce it is fsck-test/013 on 64K page sized
system:
[...]
adding new data backref on 315859712 root 287 owner 292 offset 0 found 1
btrfs unable to find ref byte nr 318504
We have several bug reports of btrfs-convert failure in
btrfs_run_delayed_refs().
The bug turns out to be a incorrect backport of delayed ref handling in
transaction commit.
In kernel we have a loop to exhause both delayed refs and dirty blocks,
as btrfs_write_dirty_block_groups() can generate ne
21 matches
Mail list logo
