similar to: [PATCH] Btrfs: fix race condition between writting and scrubing supers

Since there is a filesystem state, we should deal with it carefully at mount, umount and remount. - At mount, the FS state should be checked if there is error on these FS. If it does have, btrfsck is recommended. - At umount, the FS state should be saved into disk for consistency. Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com> --- fs/btrfs/disk-io.c | 47

I''m trying to use this feature of qgroup: btrfs qgroup assign <srcid> <destid> <path> Assigns the lower level qgroup src to the higher level qgroup dest in the btrfs found in <path>. It is used to build qgroup hierarchies. However, I fail to understand how this feature should work, and I''m getting "ERROR: bad relation requested":

If we change our default subvolume, btrfs receive will fail to find subvolume. To fix this problem, i have two ideas. 1.make btrfs snapshot ioctl support passing source subvolume''s objectid 2.when we want to using interval subvolume path, we mount it other place that use subvolume 5 as its default subvolume. We''d better use the second approach because it won''t bother

When using "-U" option with btrfs-corrupt-block, it will cause a segfault due to a missing break in getopt switch. Reported-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com> Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com> --- btrfs-corrupt-block.c | 1 + 1 file changed, 1 insertion(+) diff --git a/btrfs-corrupt-block.c b/btrfs-corrupt-block.c index f0c14a9..a2828d4 100644

If you look the code carefully, you will see all the tree_mod_alloc() has to use GFP_ATOMIC. However, the original code pass the wrong arg gfp_t in some places, this dosen''t cause any problems, because in the tree_mod_alloc(), it ignores arg gfp_t and just use GFP_ATOMIC directly, this is not good. However, i think we should try best not to allocate with GFP_ATOMIC, so i keep the gfp_t

This series adds an initial implementation for scrub. It works quite straightforward. The usermode issues an ioctl for each device in the fs. For each device, it enumerates the allocated device chunks. For each chunk, the contained extents are enumerated and the data checksums fetched. The extents are read sequentially and the checksums verified. If an error occurs (checksum or EIO), a good copy

Hello All I read this thread Resilver/scrub times? for a few minutes and I have recognize that I dont know the different between Resilvering and Scrubing. Shame on me. :-( I dont find some declarations in the man-pages and I know the command to start scrubing "zpool scrub tank" but what is the command to start resilver and what is the different? -- Best Regards Alexander Dezember, 20

Hi, Doing some extensive benchmarks on BTRFS, I encountered a kernel bug in BTRFS (as reported in dmesg) Maybe the information below can help you making btrfs better. Situation Doing an intensive sequential write on a SAS 3TB disk drive (SEAGATE ST33000652SS) with 128 threads with Sysbench. Device is connected through an HBA. Blocksize was 256k ; Kernel is 3.3.0 (x86_64) ; Btrfs is version

When making btrfs filesystem. we firstly write root leaf to specified filed, and then we recow the root. If we don''t recow, some trees are not in the correct block group. Steps to reproduce: dd if=/dev/zero of=test.img bs=1M count=100 mkfs.btrfs -f test.img btrfs-debug-tree test.img extent tree key (EXTENT_TREE ROOT_ITEM 0) leaf 4210688 items 10 free space 3349 generation 4 owner 2

Memory leaks found by the tool--valgrind along with static reviewing. Based on Daivd''s branch ''integration-20130903''. Gui Hecheng (5): btrfs-progs:free local variable buf upon unsuccessful returns btrfs-progs:local variable memory freed btrfs-progs: missing tree-freeing statements added btrfs-progs:free the local list pending_list in btrfs_scan_one_dir

zpool status shows a few checksum errors against 1 device in a raidz1 3 disk array and no read or write errors against that device. The pool marked as degraded. Is there a difference if you clear the errors for the pool before you scrub versus scrubing then clearing the errors? I''m not sure if the clearing errors prior to a scrub will replicate out any bad blocks that were identified as

From: Wang Shilong <wangsl-fnst@cn.fujitsu.com> This patch tries to stop users to create/destroy qgroup level 0, users can only create/destroy qgroup level more than 0. See the fact: a subvolume/snapshot qgroup was created automatically when creating subvolume/snapshot, so creating a qgroup level 0 can''t be a subvolume/snapshot qgroup, the only way to use it is that assigning

From: Wang Shilong <wangsl-fnst@cn.fujitsu.com> The check work has been done just before the function btrfs_clean_quota_tree is called, it is not necessary to check it again, remove it. Signed-off-by: Wang Shilong <wangsl-fnst@cn.fujitsu.com> --- fs/btrfs/qgroup.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c index

From: Wang Shilong <wangsl-fnst@cn.fujitsu.com> commit eb6b88d92c6df083dd09a8c471011e3788dfd7c6 leads into another bug. If it is just because qgroup_reserve fails, the function btrfs_qgroup_free should not be called, otherwise, it will cause the wrong quota accounting. Signed-off-by: Wang Shilong <wangsl-fnst@cn.fujitsu.com> --- fs/btrfs/extent-tree.c | 11 ++++++----- 1 files

The reason the deadlock is that: Task Btrfs-cleaner umount() down_write(&s->s_umount) sync_filesystem() do auto-defragment and produce lots of dirty pages close_ctree() wait for the end of btrfs-cleaner start_transaction reserve space shrink_delalloc() writeback_inodes_sb_nr_if_idle()

I think I have this one solved, I hope. I think what Andreas and I are running into are a few different assertions. One being the LVM lvm_do_pv_flush caused assertion which is related directly to invalidate_buffers() being called which then triggers refile_buffer() on a journaled buffer, which appears clean in all other ways according to the checks in refile_buffer(). The following is what

I previously wrote: > I have come across what appears to be a bug in __invalidate_buffers() > w.r.t. the change in ext3-0.0.6 using BH_JDirty instead of BH_Dirty > for buffers held in the journal. If invalidate_buffers() is called > on a device (LVM likes to do this a lot, for whatever reason), it yanks > JDirty buffers out from underneath the journal layer, and causes an > oops

Hi. I got following BUG trace. This is violation of BUG_ON(!buffer_locked(bh)) check on submit_bh() function. In write_dev_supers(), if wait parameter is set and buffer_uptodate() check is negative, submit_bh() is executed and hit above BUG_ON. So I fixed this issue. Thanks. Jun 9 00:41:32 dl580 kernel: ------------[ cut here ]------------ Jun 9 00:41:32 dl580 kernel: kernel BUG at

for s10u2, documentation recommends 3 to 9 devices in raidz. what is the basis for this recommendation? i assume it is performance and not failure resilience, but i am just guessing... [i know, recommendation was intended for people who know their raid cold, so it needed no further explanation] thanks... oz -- ozan s. yigit | oz at somanetworks.com | 416 977 1414 x 1540 I have a hard time

The kernel side for rescan, which is needed if you want to enable qgroup tracking on a non-empty volume. The first patch splits btrfs_qgroup_account_ref into readable ans reusable units. The second patch adds the rescan implementation (refer to its commit message for a description of the algorithm). The third patch starts an automatic rescan when qgroups are enabled. It is only separated to