Re: [RFC PATCH] Decrease Metadata Fragment By Using a Caterpillar Band Method(intro modified)
On 05/28/2012 02:06 PM, WeiFeng Liu wrote: > On Sunday, May 27, 2012 at 5:44 PM, Liu Bo wrote: > >> Hi, >> >> Thanks for working on this. >> >> Do you have any performance number? >> >> The idea is an interesting one, but I have no idea if it really >> works, because blocks are >> still fragments: >> >> | 16k | 16k |16k| >> ||A|||B|||C|| >> >> >> Or am I missing something? >> >> thanks, >> liubo >> > > Hi, Liu Bo > > I noticed your graphic and what you said, "still fragments" > thanks you. > > According my patch's logic, any COWs for tree block A will be limited in it's > 16k caterpillar band in the example, at least theoretically, and so tree block > B, like the following: > > |<-- A circulated in 16k -->| |<-- B circulated in 16k -->| > |--a-->|--b-->|--c-->|--d-->| |--a-->|--b-->|--c-->|--d-->| > | | | | > |-<-| |-<-| > > Liu Bo, are the fragments you mentioned referenced to the ones in a > caterpillar > or ones out of a caterpillar? if they are in a caterpillar, nothing would be > worried, because they are supposed to stay there forever, and that efficiency > is just what I want. > Yes, I refer to the space hole between A and B, which may not make readahead happy. But I'm not that sure, anyway, the performance number will tell us the truth :) thanks, liubo > To a certain degree, using a caterpillar for a tree block is somewhat > similar with the way superblock runs, a superblock circularly updated in a > cluster of DISCONTINUOUS blocks within a large range, and I use a caterpillar > band to force a tree block updated circularly in a continuous blocks within a > compact area. > > Sorry, I haven't yet take performance test for my patch now, a bit more times > are still needed for me to check the possible bugs in code's routes before > tests, and any comments are welcome. > > Thanks all you. > > WeiFeng Liu > 523f28f9b3d9c710cacc31dbba644efb1678cf62 > > -- 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
Re: [RFC PATCH] Decrease Metadata Fragment By Using a Caterpillar Band Method(intro modified)
On 05/28/12 10:41, Liu Bo wrote: On 05/28/2012 02:06 PM, WeiFeng Liu wrote: On Sunday, May 27, 2012 at 5:44 PM, Liu Bo wrote: Hi, Thanks for working on this. Do you have any performance number? The idea is an interesting one, but I have no idea if it really works, because blocks are still fragments: | 16k | 16k |16k| ||A|||B|||C|| Or am I missing something? thanks, liubo Hi, Liu Bo I noticed your graphic and what you said, "still fragments" thanks you. According my patch's logic, any COWs for tree block A will be limited in it's 16k caterpillar band in the example, at least theoretically, and so tree block B, like the following: |<-- A circulated in 16k -->| |<-- B circulated in 16k -->| |--a-->|--b-->|--c-->|--d-->| |--a-->|--b-->|--c-->|--d-->| | | | | |-<-| |-<-| Liu Bo, are the fragments you mentioned referenced to the ones in a caterpillar or ones out of a caterpillar? if they are in a caterpillar, nothing would be worried, because they are supposed to stay there forever, and that efficiency is just what I want. Yes, I refer to the space hole between A and B, which may not make readahead happy. But I'm not that sure, anyway, the performance number will tell us the truth :) When using spinning drives, this will basically limit us to 1/4th of platter speed, which is still quite a lot compared to random reads. But there are more aspects to it. This patch assumes that the layout that the trees takes on first write is a good one. I'm not sure this is a valid assumption at all. Another problem I see is that this loses us the big advantage that in btrfs all metadata writes can happen sequentially, as all cowed blocks can be allocated next to each other (as long as there's space). So I expect writing tree updates to become much more costly. All in all, in might be a strategy worth looking at in read-mostly situations. But again, the benchmarks might prove me wrong ;) -Arne thanks, liubo To a certain degree, using a caterpillar for a tree block is somewhat similar with the way superblock runs, a superblock circularly updated in a cluster of DISCONTINUOUS blocks within a large range, and I use a caterpillar band to force a tree block updated circularly in a continuous blocks within a compact area. Sorry, I haven't yet take performance test for my patch now, a bit more times are still needed for me to check the possible bugs in code's routes before tests, and any comments are welcome. Thanks all you. WeiFeng Liu 523f28f9b3d9c710cacc31dbba644efb1678cf62 -- 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 -- 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
Re: [PATCH 1/2] btrfs: Drop unused function btrfs_abort_devices()
On Fri, May 25, 2012 at 11:10:21AM +0800, Asias He wrote:
> 1) This function is not used anywhere.
This was added in 49b25e0540904be0bf558b84475c69d72e4de66e adding a
transaction abort infrastructure. I'm not sure if Jeff had some
intentions with it or whether it got obsolete during the patchset long
evolution, CCed.
david
> 2) Using the blk_abort_queue() to abort the queue seems not correct.
> blk_abort_queue() is used for timeout handling (block/blk-timeout.c).
>
> Cc: Chris Mason
> Cc: linux-btrfs@vger.kernel.org
> Cc: Jens Axboe
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Asias He
> ---
> fs/btrfs/disk-io.c | 13 -
> fs/btrfs/disk-io.h |1 -
> 2 files changed, 14 deletions(-)
>
> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> index e1fe74a..3521866 100644
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -2902,19 +2902,6 @@ int write_ctree_super(struct btrfs_trans_handle *trans,
> return ret;
> }
>
> -/* Kill all outstanding I/O */
> -void btrfs_abort_devices(struct btrfs_root *root)
> -{
> - struct list_head *head;
> - struct btrfs_device *dev;
> - mutex_lock(&root->fs_info->fs_devices->device_list_mutex);
> - head = &root->fs_info->fs_devices->devices;
> - list_for_each_entry_rcu(dev, head, dev_list) {
> - blk_abort_queue(dev->bdev->bd_disk->queue);
> - }
> - mutex_unlock(&root->fs_info->fs_devices->device_list_mutex);
> -}
> -
> void btrfs_free_fs_root(struct btrfs_fs_info *fs_info, struct btrfs_root
> *root)
> {
> spin_lock(&fs_info->fs_roots_radix_lock);
> diff --git a/fs/btrfs/disk-io.h b/fs/btrfs/disk-io.h
> index ab1830a..05b3fab 100644
> --- a/fs/btrfs/disk-io.h
> +++ b/fs/btrfs/disk-io.h
> @@ -89,7 +89,6 @@ int btrfs_add_log_tree(struct btrfs_trans_handle *trans,
> int btrfs_cleanup_transaction(struct btrfs_root *root);
> void btrfs_cleanup_one_transaction(struct btrfs_transaction *trans,
> struct btrfs_root *root);
> -void btrfs_abort_devices(struct btrfs_root *root);
>
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> void btrfs_init_lockdep(void);
--
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
Make existing snapshots read-only?
Is there any way to mark existing snapshots as read-only? Making new ones read-only is easy enough, but what about existing ones? Thanks. -- Bruce Guenter http://untroubled.org/ signature.asc Description: Digital signature
Re: Newbie questions on some of btrfs code...
Hi Jan,
>> Let's say that slot[0] of the current leaf (A) has key=10. And let's
>> say that its parent node (N) has key=5 (and not 10). Let's say we have
>> a previous leaf (B), whose last slot has key=2.
>> If such tree is valid, then: btrfs_prev_leaf() will search for key==9.
>> Then btrfs_search_slot() would bring us node N and leaf A again,
>> wouldn't it? Because key(N)<=9. So we will receive leaf A back, and
>> will think that there is no previous leaf, while there is.
>> What am I missing here?
>
> It wouldn't. btrfs_search_slot always sets up the path such that it
> points to the position where such an key would be inserted. And we never
> insert at the beginning of a leaf. So in your example, this would be at
> the end of leaf B: your path object will have nodes[1] = N, nodes[0] = B
> and slots[0] = number_of_slots_used_in_B + 1.
I have re-looked at btrfs_search_slot, and don't see how it would end
up in leaf B. The bin_search() function will clearly return the slot
*after* the slot of N that has key==5 (which is the parent slot of A).
So then the following code:
if (level != 0) {
int dec = 0;
if (ret && slot > 0) {
dec = 1;
slot -= 1;
}
will bring us back into the slot of N with key=5. And we will go to
leaf A. While if key(N) of that slot was 10, we would never have ended
up in that slot, unless there is no lesser key in the tree. Actually,
it looks like "no lesser key" is the only case when we can get ret==1
and slot==0. Except perhaps an empty leaf, which I am not sure can
happen.
But I may be way off here, as my understanding is still pretty limited.
Thanks!
Alex.
--
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
Re: Make existing snapshots read-only?
On 2012/5/29 2:37, Bruce Guenter wrote: > > Is there any way to mark existing snapshots as read-only? Making new > ones read-only is easy enough, but what about existing ones? > We have code in the kernel side, so what we need to do is to update btrfs-progs, which is trivial. -- 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
