Re: [PATCH RFC] btrfs: introduce a separate mutex for caching_block_groups list

Hi Liu, On Wed, Mar 22, 2017 at 1:40 AM, Liu Bo <bo.li@oracle.com> wrote: > On Sun, Mar 19, 2017 at 07:18:59PM +0200, Alex Lyakas wrote: >> We have a commit_root_sem, which is a read-write semaphore that protects the >> commit roots. >> But it is also used to protec

Re: include linux kernel headers for btrfs filesystem

Ilan, On Mon, Mar 20, 2017 at 10:33 AM, Ilan Schwarts wrote: > I need to cast struct inode to struct btrfs_inode. > in order to do it, i looked at implementation of btrfs_getattr. > > the code is simple: > struct btrfs_inode *btrfsInode; > btrfsInode = BTRFS_I(inode); > > in

[PATCH RFC] btrfs: introduce a separate mutex for caching_block_groups list

sed on one of the latest kernels, because here btrfs is part of the larger system, and upgrading the kernel is a significant effort. Hence marking the patch as RFC. Hopefully, this patch still has some value to the community. Signed-off-by: Alex Lyakas <a...@zadarastorage.com> diff --git a/fs/bt

Re: [PATCH] Btrfs: deal with unexpected return value in flush_space

David, Holger, Thank you for picking up that old patch of mine. Alex. On Fri, Jul 29, 2016 at 8:53 PM, Liu Bo wrote: > On Fri, Jul 29, 2016 at 07:01:50PM +0200, David Sterba wrote: >> On Thu, Jul 28, 2016 at 11:49:14AM -0700, Liu Bo wrote: >> > > For reviewers - this

[RCF - PATCH] btrfs: do not ignore errors from primary superblock

RFC: This patch not for merging, but only for review and discussion. When mounting, we consider only the primary superblock on each device. But when writing the superblocks, we might silently ignore errors from the primary superblock, if we succeeded to write secondary superblocks. In such case,

Re: [PATCH v4 6/9] Btrfs: implement the free space B-tree

Hi Omar, Chris, I have reviewed the free-space-tree code. It is a very nice feature. However, I have a basic understanding question. Let's say we are running a delayed ref which inserts a new EXTENT_ITEM into the extent tree, e.g., we are in alloc_reserved_file_extent. At this point we call

Re: [PATCH v8 00/27][For 4.7] Btrfs: Add inband (write time) de-duplication framework

Hello Qu, Wang, On Wed, Mar 30, 2016 at 2:34 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > Alex Lyakas wrote on 2016/03/29 19:22 +0200: >> >> Greetings Qu Wenruo, >> >> I have reviewed the dedup patchset found in the github account you >> men

Re: [PATCH v8 00/27][For 4.7] Btrfs: Add inband (write time) de-duplication framework

Thanks for your comments, Qu. Alex. On Wed, Mar 30, 2016 at 2:34 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > Alex Lyakas wrote on 2016/03/29 19:22 +0200: >> >> Greetings Qu Wenruo, >> >> I have reviewed the dedup patchset found in the github a

Re: [PATCH v8 00/27][For 4.7] Btrfs: Add inband (write time) de-duplication framework

Greetings Qu Wenruo, I have reviewed the dedup patchset found in the github account you mentioned. I have several questions. Please note that by all means I am not criticizing your design or code. I just want to make sure that my understanding of the code is proper. 1) You mentioned in several

Re: [RFC - PATCH] btrfs: do not write corrupted metadata blocks to disk

t 9:46 AM, Alex Lyakas <a...@zadarastorage.com> wrote: >> Thank you, Filipe, for your review. >> >> On Mon, Feb 22, 2016 at 3:05 AM, Filipe Manana <fdman...@kernel.org> wrote: >>> On Sun, Feb 21, 2016 at 3:36 PM, Alex Lyakas <a...@zadarastorage.com> wrote

[PATCH 1/2] btrfs: csum_tree_block: return proper errno value

Signed-off-by: Alex Lyakas <a...@zadarastorage.com> --- fs/btrfs/disk-io.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 4545e2e..4420ab2 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -296,52 +

[PATCH 2/2] btrfs: do not write corrupted metadata blocks to disk

will, but it is better than to have a silent metadata corruption on disk. Signed-off-by: Alex Lyakas <a...@zadarastorage.com> --- fs/btrfs/disk-io.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 4420ab2..c

Re: [RFC - PATCH] btrfs: do not write corrupted metadata blocks to disk

Thank you, Filipe, for your review. On Mon, Feb 22, 2016 at 3:05 AM, Filipe Manana <fdman...@kernel.org> wrote: > On Sun, Feb 21, 2016 at 3:36 PM, Alex Lyakas <a...@zadarastorage.com> wrote: >> csum_dirty_buffer was issuing a warning in case the extent buffer &g

[RFC - PATCH] btrfs: do not write corrupted metadata blocks to disk

that the extent buffer doesn't look alright. The caller up the chain may BUG_ON on this, for example flush_epd_write_bio will, but it is better than to have a silent metadata corruption on disk. Note: this patch has been properly tested on 3.18 kernel only. Signed-off-by: Alex Lyakas

Re: [PATCH V2] Btrfs: find_free_extent: Do not erroneously skip LOOP_CACHING_WAIT state

[Resending in plain text, apologies.] Hi Chandan, Josef, Chris, I am not sure I understand the fix to the problem. It may happen that when updating the device tree, we need to allocate a new chunk via do_chunk_alloc (while we are holding the device tree root node locked). This is a legitimate

Re: [PATCH 1/2 v3] Btrfs: fix regression when running delayed references

Hi Filipe Manana, My understanding of selecting delayed refs to run or merging them is far from complete. Can you please explain what will happen in the following scenario: 1) Ref1 is created, as you explain 2) Somebody calls __btrfs_run_delayed_refs() and runs Ref1, and we end up with an

Re: [PATCH] Btrfs: fix quick exhaustion of the system array in the superblock

Hi Filipe Manana, Can't the call to btrfs_create_pending_block_groups() cause a deadlock, like in http://www.spinics.net/lists/linux-btrfs/msg48744.html? Because this call updates the device tree, and we may be calling do_chunk_alloc() from find_free_extent() when holding a lock on the device

Re: [PATCH 1/2 v3] Btrfs: fix regression when running delayed references

Hi Filipe, Thank you for the explanation. On Sun, Dec 13, 2015 at 5:43 PM, Filipe Manana <fdman...@kernel.org> wrote: > On Sun, Dec 13, 2015 at 10:51 AM, Alex Lyakas <a...@zadarastorage.com> wrote: >> Hi Filipe Manana, >> >> My understanding of selecting de

Re: [PATCH] Btrfs: fix quick exhaustion of the system array in the superblock

<fdman...@kernel.org> wrote: > On Sun, Dec 13, 2015 at 10:29 AM, Alex Lyakas <a...@zadarastorage.com> wrote: >> Hi Filipe Manana, >> >> Can't the call to btrfs_create_pending_block_groups() cause a >> deadlock, like in >> http://www.spinics.net/lists/li

Re: [RFC PATCH] btrfs: flush_space: treat return value of do_chunk_alloc properly

Thu, Dec 3, 2015 at 8:14 PM, Liu Bo <bo.li@oracle.com> wrote: > On Thu, Dec 03, 2015 at 06:51:03PM +0200, Alex Lyakas wrote: >> do_chunk_alloc returns 1 when it succeeds to allocate a new chunk. >> But flush_space will not convert this to 0, and will also return 1. >>

Re: [RFC PATCH] btrfs: flush_space: treat return value of do_chunk_alloc properly

n ret; So it will return -ENOSPC. Signed-off-by: Alex Lyakas <a...@zadarastorage.com> Reviewed-by: Josef Bacik <jba...@fb.com> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 4b89680..1ba3f0d 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -4727,7

[RFC PATCH] btrfs: flush_space: treat return value of do_chunk_alloc properly

do_chunk_alloc returns 1 when it succeeds to allocate a new chunk. But flush_space will not convert this to 0, and will also return 1. As a result, reserve_metadata_bytes will think that flush_space failed, and may potentially return this value "1" to the caller (depends how reserve_metadata_bytes

Re: [PATCH] btrfs: clear bio reference after submit_one_bio()

nd comment on patches. Alex. On Thu, Nov 5, 2015 at 3:08 PM, Holger Hoffstätte <holger.hoffstae...@googlemail.com> wrote: > On 10/11/15 20:09, Alex Lyakas wrote: >> Hi Naota, >> >> What happens if btrfs_bio_alloc() in submit_extent_page fails? Then we >> return -ENOME

Re: [PATCH] btrfs: clear bio reference after submit_one_bio()

Hi Naota, What happens if btrfs_bio_alloc() in submit_extent_page fails? Then we return -ENOMEM to the caller, but we do not set *bio_ret to NULL. And if *bio_ret was non-NULL upon entry into submit_extent_page, then we had submitted this bio before getting to btrfs_bio_alloc(). So should

Re: [PATCH] Btrfs: check pending chunks when shrinking fs to avoid corruption

Hi Filipe, Looking the code of this patch, I see that if we discover a pending chunk, we unlock the chunk mutex, commit the transaction (which completes the allocation of all pending chunks and inserts relevant items into the device tree and chunk tree), and retry the search. However, after we

Re: [PATCH v5 04/18] btrfs: Add threshold workqueue based on kernel workqueue

Hi Qu, On Fri, Feb 28, 2014 at 4:46 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote: The original btrfs_workers has thresholding functions to dynamically create or destroy kthreads. Though there is no such function in kernel workqueue because the worker is not created manually, we can still use

Re: question about should_cow_block() and BTRFS_HEADER_FLAG_WRITTEN

receive from the free-space cache, which is a logical coordinate by which EXTENT_ITEMs are sorted in the extent tree. On Mon, Jul 13, 2015 at 7:02 PM, Chris Mason c...@fb.com wrote: On Mon, Jul 13, 2015 at 06:55:29PM +0200, Alex Lyakas wrote: Filipe, Thanks for the explanation. Those reasons were

Re: question about should_cow_block() and BTRFS_HEADER_FLAG_WRITTEN

at 6:15 PM, Alex Lyakas a...@zadarastorage.com wrote: Greetings, Looking at the code of should_cow_block(), I see: if (btrfs_header_generation(buf) == trans-transid !btrfs_header_flag(buf, BTRFS_HEADER_FLAG_WRITTEN) ... So if the extent buffer has been written to disk, and now is changed

question about should_cow_block() and BTRFS_HEADER_FLAG_WRITTEN

Greetings, Looking at the code of should_cow_block(), I see: if (btrfs_header_generation(buf) == trans-transid !btrfs_header_flag(buf, BTRFS_HEADER_FLAG_WRITTEN) ... So if the extent buffer has been written to disk, and now is changed again in the same transaction, we insist on COW'ing it.

Re: [PATCH] btrfs-progs: rebuild missing block group during chunk recovery if possible

Hi Qu, On Wed, Dec 24, 2014 at 3:09 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote: Original Message Subject: Re: [PATCH] btrfs-progs: rebuild missing block group during chunk recovery if possible From: Alex Lyakas alex.bt...@zadarastorage.com To: Qu Wenruo quwen

Re: How btrfs-find-root knows that the block is actually a root?

Hi Qu, On Tue, Dec 23, 2014 at 7:27 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote: Original Message Subject: How btrfs-find-root knows that the block is actually a root? From: Alex Lyakas alex.bt...@zadarastorage.com To: linux-btrfs linux-btrfs@vger.kernel.org Date: 2014年12月

Re: [PATCH] btrfs-progs: rebuild missing block group during chunk recovery if possible

Hi Qu, On Thu, Oct 30, 2014 at 4:54 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote: Before the patch, chunk will be considered bad if the corresponding block group is missing, even the only uncertain data is the 'used' member of the block group. This patch will try to recalculate the 'used'

How btrfs-find-root knows that the block is actually a root?

Greetings, I am looking at the code of search_iobuf() in btrfs-find-root.c.(3.17.3) I see that we probe nodesize blocks one by one, and for each block we check: - its owner is what we are looking for - its header-bytenr is what we are looking at currently - its level is not too small - it has

Re: [PATCH] Btrfs: update commit root on snapshot creation after orphan cleanup

, Alex Lyakas alex.bt...@zadarastorage.com wrote: Hi Filipe, It's quite possible I don't fully understand the issue. It seems that we are creating a read-only snapshot, commit a transaction, and then go and modify the snapshot once again, by deleting all the ORPHAN_ITEMs we have in its file tree

Re: [PATCH] Btrfs: update commit root on snapshot creation after orphan cleanup

Hi Filipe, It's quite possible I don't fully understand the issue. It seems that we are creating a read-only snapshot, commit a transaction, and then go and modify the snapshot once again, by deleting all the ORPHAN_ITEMs we have in its file tree (btrfs_orphan_cleanup). Shouldn't all this be part

Re: Snapshot aware defrag and qgroups thoughts

Hi Josef, thanks for the detailed description of how the extent tree works! When I was digging through that in the past, I made some slides to remember all the call chains. Maybe somebody finds that useful to accompany your notes.

Re: safe/necessary to balance system chunks?

On Fri, Apr 25, 2014 at 10:14 PM, Hugo Mills h...@carfax.org.uk wrote: On Fri, Apr 25, 2014 at 02:12:17PM -0400, Austin S Hemmelgarn wrote: On 2014-04-25 13:24, Chris Murphy wrote: On Apr 25, 2014, at 8:57 AM, Steve Leung sjle...@shaw.ca wrote: Hi list, I've got a 3-device RAID1

Re: [PATCH v6] Btrfs: fix memory leak of orphan block rsv

: On Mon, Nov 4, 2013 at 12:16 PM, Alex Lyakas alex.bt...@zadarastorage.com wrote: Hi Filipe, any luck with this patch?:) Hey Alex, I haven't digged further, but I remember I couldn't reproduce your issue (with latest btrfs-next of that day) of getting the free space inodes created even when

Re: snapshot send with parent question

Michael, btrfs-send doesn't really know or care how did you manage to get from a to c. It is able to compare any two RO subvolumes (not necessarily related by snapshot operations), and produce a stream of commands that transfer a-content into c-content. Send assumes that at a receive side, you

Re: [PATCH] Btrfs: correctly determine if blocks are shared in btrfs_compare_trees

Hi Filipe, Can you please explain more what is the scenario you are worried about. Let's say we have two FS trees (subvolumes) subv1 and subv2, subv2 being a RO snapshot of subv1. And they have a shared subtree at logical==X. Now we change subv1, so its subtree is COW'ed and some other logical

Re: [PATCH] Btrfs: attach delayed ref updates to delayed ref heads

Hi Josef, I have a question about update_existing_head_ref() logic. The question is not specific to the rework that you have done. You have a code like this: if (ref-must_insert_reserved) { /* if the extent was freed and then * reallocated before the delayed ref *

Re: [PATCH] Btrfs: fix memory leak in btrfs_create_tree()

Hi Tsutomu Itoh, On Thu, Mar 21, 2013 at 6:32 AM, Tsutomu Itoh t-i...@jp.fujitsu.com wrote: We should free leaf and root before returning from the error handling code. Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com --- fs/btrfs/disk-io.c | 12 +--- 1 file changed, 9

Re: [RFC PATCH 5/5] Btrfs: fix broken free space cache after the system crashed

, the transaction commits and we crash, then yes, the allocation is lost. Alex. On Tue, Mar 4, 2014 at 8:04 AM, Miao Xie mi...@cn.fujitsu.com wrote: On sat, 1 Mar 2014 20:05:01 +0200, Alex Lyakas wrote: Hi Miao, On Wed, Jan 15, 2014 at 2:00 PM, Miao Xie mi...@cn.fujitsu.com wrote: When we mounted

Re: [RFC PATCH 5/5] Btrfs: fix broken free space cache after the system crashed

Hi Miao, On Wed, Jan 15, 2014 at 2:00 PM, Miao Xie mi...@cn.fujitsu.com wrote: When we mounted the filesystem after the crash, we got the following message: BTRFS error (device xxx): block group 4315938816 has wrong amount of free space BTRFS error (device xxx): failed to load free

Re: [PATCH] Btrfs: fix a deadlock on chunk mutex

Hello Josef, On Tue, Dec 18, 2012 at 3:52 PM, Josef Bacik jba...@fusionio.com wrote: On Wed, Dec 12, 2012 at 06:52:37PM -0700, Liu Bo wrote: An user reported that he has hit an annoying deadlock while playing with ceph based on btrfs. Current updating device tree requires space from METADATA

Re: [PATCH] Btrfs: fix a deadlock on chunk mutex

: SHA1 On 02/18/2014 10:47 AM, Alex Lyakas wrote: Hello Josef, On Tue, Dec 18, 2012 at 3:52 PM, Josef Bacik jba...@fusionio.com wrote: On Wed, Dec 12, 2012 at 06:52:37PM -0700, Liu Bo wrote: An user reported that he has hit an annoying deadlock while playing with ceph based on btrfs

Re: [PATCH] btrfs: Fix 32/64-bit problem with BTRFS_SET_RECEIVED_SUBVOL ioctl

Hello Hugo, Is this issue specific to the receive ioctl? Because what you are describing applies to any user-kernel ioctl-based interface, when you compile the user-space as 32-bit, which the kernel space has been compiled as 64-bit. For that purpose, I believe, there exists the compat_ioctl

Re: [PATCH] Btrfs: return ENOSPC when target space is full

Hi Filipe, I think in the context of do_chunk_alloc(), 0 doesn't mean success. 0 means allocation was not attempted. While 1 means allocation was attempted and succeeded. -ENOSPC means allocation was attempted but failed. Any other errno deserves transaction abort. Anyways, the callers are ok with

Re: [PATCH v2] Btrfs-progs: avoid using btrfs internal subvolume path to send

Hi Miguel, On Sat, Nov 30, 2013 at 1:43 PM, Miguel Negrão miguel.negrao-li...@friendlyvirus.org wrote: Em 29-11-2013 16:37, Wang Shilong escreveu: From: Wang Shilong wangsl.f...@cn.fujitsu.com Steps to reproduce: # mkfs.btrfs -f /dev/sda # mount /dev/sda /mnt # btrfs

Re: [PATCH v7 04/13] Btrfs: disable qgroups accounting when quata_enable is 0

Hi Liu, Jan, What happens to struct qgroup_updates sitting in trans-qgroup_ref_list in case the transaction aborts? It seems that they are not freed. For example, if we are in btrfs_commit_transaction() and: - call create_pending_snapshots() - call btrfs_run_delayed_items() and this fails So we

Re: [PATCH v2] btrfs-progs: calculate disk space that a subvol could free

Hello Anand, I have sent a similar comment to your email thread in http://www.spinics.net/lists/linux-btrfs/msg27547.html I believe this approach of calculating freeable space is incorrect. Try this: - create a fresh btrfs - create a regular file - write some data into it in such a way, that it

Re: [PATCH v6] Btrfs: fix memory leak of orphan block rsv

Hi Filipe, any luck with this patch?:) Alex. On Wed, Oct 23, 2013 at 5:26 PM, Filipe David Manana fdman...@gmail.com wrote: On Wed, Oct 23, 2013 at 3:14 PM, Alex Lyakas alex.bt...@zadarastorage.com wrote: Hello, On Wed, Oct 23, 2013 at 4:35 PM, Filipe David Manana fdman...@gmail.com wrote

Re: [patch 3/7] btrfs: Add per-super attributes to sysfs

Hi Jeff, On Tue, Sep 10, 2013 at 7:24 AM, Jeff Mahoney je...@suse.com wrote: This patch adds per-super attributes to sysfs. It doesn't publish any attributes yet, but does the proper lifetime handling as well as the basic infrastructure to add new attributes. Signed-off-by: Jeff Mahoney

Re: [PATCH] btrfs-progs: calculate disk space that a subvol could free upon delete

Hi Anand, 1) so let's say I have a subvolume and a snapshot of this subvolume. So in this case, I will see Sole space = 0 for both of them, correct? Because all extents (except inline ones) are shared. 2) How is this in terms of responsiveness? On a huge subvolume, we need to iterate all the

Re: [PATCH] btrfs-progs: calculate disk space that a subvol could free upon delete

by _btrfs_mod_ref() code, called from btrfs_copy_root() during snapshot creation flow. Snapshot deletion code is the one that is smart enough to properly unshare shared tree blocks with such implicit references. What do you think? Alex. On Sat, Oct 26, 2013 at 10:49 PM, Alex Lyakas alex.bt

Re: [PATCH v6] Btrfs: fix memory leak of orphan block rsv

Hello, On Wed, Oct 23, 2013 at 4:35 PM, Filipe David Manana fdman...@gmail.com wrote: On Wed, Oct 23, 2013 at 2:33 PM, Alex Lyakas alex.bt...@zadarastorage.com wrote: Hi Filipe, On Tue, Aug 20, 2013 at 2:52 AM, Filipe David Borba Manana fdman...@gmail.com wrote: This issue is simple

Re: [PATCH] btrfs: commit transaction after deleting a subvolume

: Alex Lyakas alex.bt...@zadarastorage.com CC: Josef Bacik jba...@fusionio.com Signed-off-by: David Sterba dste...@suse.cz --- fs/btrfs/ioctl.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index e407f75..4394632 100644 --- a/fs

Re: [PATCH 2/2] Btrfs: stop caching thread if extent_commit_sem is contended

Thanks for addressing this issue, Josef! On Thu, Sep 26, 2013 at 4:26 PM, Josef Bacik jba...@fusionio.com wrote: We can starve out the transaction commit with a bunch of caching threads all running at the same time. This is because we will only drop the extent_commit_sem if we need_resched(),

[PATCH] Notify caching_thread()s to give up on extent_commit_sem when needed.

this problem happens, and whether the fix goes in the right direction. Signed-off-by: Alex Lyakas alex.bt...@zadarastorage.com --- fs/btrfs/ctree.h |7 +++ fs/btrfs/disk-io.c |1 + fs/btrfs/extent-tree.c |9 + fs/btrfs/transaction.c |2 +- 4 files changed, 14

Re: [PATCH] Notify caching_thread()s to give up on extent_commit_sem when needed.

On Thu, Aug 29, 2013 at 10:55 PM, Josef Bacik jba...@fusionio.com wrote: On Thu, Aug 29, 2013 at 10:09:29PM +0300, Alex Lyakas wrote: Hi Josef, On Thu, Aug 29, 2013 at 5:38 PM, Josef Bacik jba...@fusionio.com wrote: On Thu, Aug 29, 2013 at 01:31:05PM +0300, Alex Lyakas wrote

Re: btrfs:async-thread: atomic_start_pending=1 is set, but it's too late

Thanks, Chris, Josef, for confirming! On Thu, Aug 29, 2013 at 11:08 PM, Chris Mason clma...@fusionio.com wrote: Quoting Josef Bacik (2013-08-29 16:03:06) On Mon, Aug 26, 2013 at 05:16:42PM +0300, Alex Lyakas wrote: Greetings all, I see a following issue with spawning new threads

Re: [PATCH] Btrfs: stop all workers before cleaning up roots

Hi Josef, On Thu, May 30, 2013 at 11:58 PM, Josef Bacik jba...@fusionio.com wrote: Dave reported a panic because the extent_root-commit_root was NULL in the caching kthread. That is because we just unset it in free_root_pointers, which is not the correct thing to do, we have to either wait

Re: [PATCH] Btrfs: update drop progress before stopping snapshot dropping

the snapshot dropping without updating the drop progress. So the next time we go to resume we will BUG_ON() because we can't find the extent we left off at because we never updated it. This patch fixes the problem. Cc: sta...@vger.kernel.org Reported-by: Alex Lyakas alex.bt

Re: [PATCH] Btrfs: fix all callers of read_tree_block

Hi Josef, On Tue, Apr 23, 2013 at 9:20 PM, Josef Bacik jba...@fusionio.com wrote: We kept leaking extent buffers when mounting a broken file system and it turns out it's because not everybody uses read_tree_block properly. You need to check and make sure the extent_buffer is uptodate before

Re: [PATCH] Btrfs: fix lock leak when resuming snapshot deletion

the extent buffer from cache. Thanks, Reported-by: Alex Lyakas alex.bt...@zadarastorage.com Signed-off-by: Josef Bacik jba...@fusionio.com --- fs/btrfs/extent-tree.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index

Re: [PATCH v3] btrfs: clean snapshots one by one

Hi, On Thu, Jul 4, 2013 at 10:52 PM, Alex Lyakas alex.bt...@zadarastorage.com wrote: Hi David, On Thu, Jul 4, 2013 at 8:03 PM, David Sterba dste...@suse.cz wrote: On Thu, Jul 04, 2013 at 06:29:23PM +0300, Alex Lyakas wrote: @@ -7363,6 +7365,12 @@ int btrfs_drop_snapshot(struct btrfs_root

Re: [PATCH v3] btrfs: clean snapshots one by one

Hi David, I believe this patch has the following problem: On Tue, Mar 12, 2013 at 5:13 PM, David Sterba dste...@suse.cz wrote: Each time pick one dead root from the list and let the caller know if it's needed to continue. This should improve responsiveness during umount and balance which at

Re: [PATCH v3] btrfs: clean snapshots one by one

Hi David, On Thu, Jul 4, 2013 at 8:03 PM, David Sterba dste...@suse.cz wrote: On Thu, Jul 04, 2013 at 06:29:23PM +0300, Alex Lyakas wrote: @@ -7363,6 +7365,12 @@ int btrfs_drop_snapshot(struct btrfs_root *root, wc-reada_count = BTRFS_NODEPTRS_PER_BLOCK(root); while (1

Re: question about transaction-abort-related commits

On Sun, Jun 30, 2013 at 2:36 PM, Josef Bacik jba...@fusionio.com wrote: On Sun, Jun 30, 2013 at 11:29:14AM +0300, Alex Lyakas wrote: Hi Josef, On Wed, Jun 26, 2013 at 5:16 PM, Alex Lyakas alex.bt...@zadarastorage.com wrote: Hi Josef, Can you please help me with another question. I am

Re: question about transaction-abort-related commits

Hi Josef, On Wed, Jun 26, 2013 at 5:16 PM, Alex Lyakas alex.bt...@zadarastorage.com wrote: Hi Josef, Can you please help me with another question. I am looking at your patch: Btrfs: fix chunk allocation error handling https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit

Re: [PATCH 2/3] Btrfs: fix the deadlock between the transaction start/attach and commit

Hi Miao, On Mon, Jun 17, 2013 at 4:51 AM, Miao Xie mi...@cn.fujitsu.com wrote: On sun, 16 Jun 2013 13:38:42 +0300, Alex Lyakas wrote: Hi Miao, On Thu, Jun 13, 2013 at 6:08 AM, Miao Xie mi...@cn.fujitsu.com wrote: On wed, 12 Jun 2013 23:11:02 +0300, Alex Lyakas wrote: I reviewed

Re: question about transaction-abort-related commits

. On Mon, Jun 24, 2013 at 7:24 PM, Josef Bacik jba...@fusionio.com wrote: On Sun, Jun 23, 2013 at 09:52:14PM +0300, Alex Lyakas wrote: Hello Josef, Liu, I am reviewing commits in the mainline tree: e4a2bcaca9643e7430207810653222fc5187f2be Btrfs: if we aren't committing just end the transaction if we

question about transaction-abort-related commits

Hello Josef, Liu, I am reviewing commits in the mainline tree: e4a2bcaca9643e7430207810653222fc5187f2be Btrfs: if we aren't committing just end the transaction if we error out (call end_transaction() instead of goto cleanup_transaction) - Josef f094ac32aba3a51c00e970a2ea029339af2ca048 Btrfs: fix

Re: [PATCH 2/3] Btrfs: fix the deadlock between the transaction start/attach and commit

Hi Miao, On Thu, Jun 13, 2013 at 6:08 AM, Miao Xie mi...@cn.fujitsu.com wrote: On wed, 12 Jun 2013 23:11:02 +0300, Alex Lyakas wrote: I reviewed the code starting from: 69aef69a1bc154 Btrfs: don't wait for all the writers circularly during the transaction commit until 2ce7935bf4cdf3 Btrfs

Re: [PATCH 2/3] Btrfs: fix the deadlock between the transaction start/attach and commit

kernel (manually, of course)? Or some additional things are needed that are missing in this kernel? Thanks, Alex. Thanks Miao On Wed, 10 Apr 2013 21:45:43 +0300, Alex Lyakas wrote: Hi Miao, I attempted to fix the issue by not joining a transaction that has trans-in_commit set. I did

wait_block_group_cache_progress() waits forever in case of drive failure

Greetings all, when testing drive failures, I occasionally hit the following hang: # Block group is being cached-in by caching_thread() # caching_thread() experiences an error, e.g., in btrfs_search_slot, because of drive failure: ret = btrfs_search_slot(NULL, extent_root, key, path, 0,

[no subject]

Hello all, I have the following unresponsive btrfs: btrfs_end_transaction() is called and is stuck in btrfs_tree_lock(): May 27 16:13:55 vc kernel: [ 7130.421159] kworker/u:85D 0 19859 2 0x May 27 16:13:55 vc kernel: [ 7130.421159] 880095335568

Re: [PATCH] Btrfs: clear received_uuid field for new writable snapshots

Hi Stephan, I fully understand the first part of your fix, and I believe it's quite critical. Indeed, a writable snapshot should have no evidence that it has an ancestor that was once received. Can you pls let me know that I understand the second part of your fix. In btrfs-progs the following

Re: [PATCH 2/3] Btrfs: fix the deadlock between the transaction start/attach and commit

seconds are spent in the do-while loop of btrfs_commit_transaction. Thanks, Alex. On Mon, Mar 25, 2013 at 11:11 AM, Alex Lyakas alex.bt...@zadarastorage.com wrote: Hi Miao, On Mon, Mar 25, 2013 at 3:51 AM, Miao Xie mi...@cn.fujitsu.com wrote: On Sun, 24 Mar 2013 13:13:22 +0200, Alex Lyakas wrote

Re: Backup Options

Hi David, maybe my old patch http://www.spinics.net/lists/linux-btrfs/msg19739.html can help this issue? Thanks, Alex. On Wed, Apr 3, 2013 at 8:23 PM, David Sterba dste...@suse.cz wrote: On Wed, Apr 03, 2013 at 04:33:22AM +0200, Harald Glatt wrote: However what I actually did was: # cd

Re: btrfs stuck on

Hi David, On Fri, Mar 29, 2013 at 8:12 PM, David Sterba dste...@suse.cz wrote: On Thu, Mar 21, 2013 at 11:56:37AM -0700, Ask Bjørn Hansen wrote: A few weeks ago I replaced a ZFS backup system with one backed by btrfs. A script loops over a bunch of hosts rsyncing them to each their own

Re: [PATCH v2] Btrfs: fix locking on ROOT_REPLACE operations in tree mod log

). This fixes the brand-new version of xfstest 276 as of commit cfe73f71. Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net --- Has probably been Reported-by: Alex Lyakas alex.bt...@zadarastorage.com (unconfirmed). Chages for v2: - use the correct base (current cmason/for-linus) fs/btrfs

Re: [PATCH 2/3] Btrfs: fix the deadlock between the transaction start/attach and commit

believe it's problematic? Thanks, Alex. On Mon, Feb 25, 2013 at 12:20 PM, Miao Xie mi...@cn.fujitsu.com wrote: On sun, 24 Feb 2013 21:49:55 +0200, Alex Lyakas wrote: Hi Miao, can you please explain your solution a bit more. On Wed, Feb 20, 2013 at 11:16 AM, Miao Xie mi...@cn.fujitsu.com wrote

Re: [PATCH v2] btrfs: clean snapshots one by one

Hi David, On Thu, Mar 7, 2013 at 1:55 PM, David Sterba dste...@suse.cz wrote: On Wed, Mar 06, 2013 at 10:12:11PM -0500, Chris Mason wrote: Also, I want to ask, hope this is not inappropriate. Do you also agree with Josef, that it's ok for BTRFS_IOC_SNAP_DESTROY not to commit the

Re: [PATCH v3] btrfs: clean snapshots one by one

On Tue, Mar 12, 2013 at 5:13 PM, David Sterba dste...@suse.cz wrote: Each time pick one dead root from the list and let the caller know if it's needed to continue. This should improve responsiveness during umount and balance which at some point waits for cleaning all currently queued dead

Re: [PATCH] Btrfs: fix backref walking race with tree deletions

blocks, it can find a backref for a no longer existing root. This is all good, we only must tolerate __resolve_indirect_ref returning an error and continue with the good refs found. Reported-by: Alex Lyakas alex.bt...@zadarastorage.com Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net

Re: same EXTENT_ITEM appears twice in the extent tree

So, no advice on how this could have happened? Ok, maybe it won't happen again... On Sun, Mar 3, 2013 at 5:44 PM, Alex Lyakas alex.bt...@zadarastorage.com wrote: Hi Chris, On Sun, Mar 3, 2013 at 5:28 PM, Chris Mason chris.ma...@fusionio.com wrote: On Sun, Mar 03, 2013 at 06:40:50AM -0700

same EXTENT_ITEM appears twice in the extent tree

Greetings all, I have an extent tree that looks like follows: item 22 key (27059916800 EXTENT_ITEM 16384) itemoff 2656 itemsize 24 extent refs 1 gen 164 flags 1 item 23 key (27059916800 EXTENT_ITEM 98304) itemoff 2603 itemsize 53 extent refs 1 gen

Re: same EXTENT_ITEM appears twice in the extent tree

Hi Chris, On Sun, Mar 3, 2013 at 5:28 PM, Chris Mason chris.ma...@fusionio.com wrote: On Sun, Mar 03, 2013 at 06:40:50AM -0700, Alex Lyakas wrote: Greetings all, I have an extent tree that looks like follows: item 22 key (27059916800 EXTENT_ITEM 16384) itemoff 2656 itemsize 24

Re: basic questions regarding COW in Btrfs

Hi Josef, I hope it's ok to piggy back on this thread for the following question: I see that in btrfs_cross_ref_exist()=check_committed_ref() path, there is the following check: if (btrfs_extent_generation(leaf, ei) = btrfs_root_last_snapshot(root-root_item)) goto out; So this

Re: [PATCH 2/3] Btrfs: fix the deadlock between the transaction start/attach and commit

Hi Miao, thanks for the great ASCII graphics and detailed explanation! Alex. On Mon, Feb 25, 2013 at 12:20 PM, Miao Xie mi...@cn.fujitsu.com wrote: On sun, 24 Feb 2013 21:49:55 +0200, Alex Lyakas wrote: Hi Miao, can you please explain your solution a bit more. On Wed, Feb 20, 2013 at 11:16

Re: [PATCH v2] btrfs: clean snapshots one by one

Hi David, On Fri, Mar 1, 2013 at 6:17 PM, David Sterba dste...@suse.cz wrote: Each time pick one dead root from the list and let the caller know if it's needed to continue. This should improve responsiveness during umount and balance which at some point wait for cleaning all currently queued

Re: [PATCH 2/3] Btrfs: fix the deadlock between the transaction start/attach and commit

Hi Miao, can you please explain your solution a bit more. On Wed, Feb 20, 2013 at 11:16 AM, Miao Xie mi...@cn.fujitsu.com wrote: Now btrfs_commit_transaction() does this ret = btrfs_run_ordered_operations(root, 0) which async flushes all inodes on the ordered operations list, it introduced

Re: LAST CALL FOR BTRFS-NEXT

Hi Josef, can you please consider including these two patches from Jan 28: https://patchwork.kernel.org/patch/2057051/ https://patchwork.kernel.org/patch/2057071/ I realize they have V2 label, although the cover letter had V3, this was my bad. However, they both apply to what you have now in

Re: [RFC][PATCH] btrfs: clean snapshots one by one

Hi David, thank you for addressing this issue. On Mon, Feb 11, 2013 at 6:11 PM, David Sterba dste...@suse.cz wrote: Each time pick one dead root from the list and let the caller know if it's needed to continue. This should improve responsiveness during umount and balance which at some point

Re: Deleted subvolume reappears and other cleaner issues

, after couple of seconds the machine completely freezes for me. I have not yet succeeded to determine why. Thanks, Alex. On Wed, Feb 6, 2013 at 5:14 PM, Josef Bacik jba...@fusionio.com wrote: On Thu, Jan 31, 2013 at 06:03:06AM -0700, Alex Lyakas wrote: Hi, I want to check if any of the below

Re: [PATCH 2/2] Btrfs: fix memory leak of pending_snapshot-inherit

really commits the transaction. The responsibility for the creation is passed to the pending_snapshot data structure, and so should the responsibility for the inherit struct. -Arne Reported-by: Alex Lyakas alex.bt...@zadarastorage.com Cc: Arne Jansen sensi...@gmx.net Signed-off-by: Miao Xie

Re: Deleted subvolume reappears and other cleaner issues

Can anyone please comment on below? On Thu, Jan 31, 2013 at 3:03 PM, Alex Lyakas alex.bt...@zadarastorage.com wrote: Hi, I want to check if any of the below issues are worth/should be fixed: # btrfs_ioctl_snap_destroy() does not commit a transaction. As a result, user can ask to delete

Leaking btrfs_qgroup_inherit on snapshot creation?

Hi Jan, Arne, I see this code in create_snapshot: if (inherit) { pending_snapshot-inherit = *inherit; *inherit = NULL;/* take responsibility to free it */ } So, first thing I think it should be: if (*inherit) because in

Deleted subvolume reappears and other cleaner issues

Hi, I want to check if any of the below issues are worth/should be fixed: # btrfs_ioctl_snap_destroy() does not commit a transaction. As a result, user can ask to delete a subvol, he receives ok back. Even if user does btrfs sub list, he will not see the deleted subvol (even though the

  1   2   3   >