[PATCH] Btrfs: cleanup some BUG_ON()

This patch changes some BUG_ON() to the error return. (but, most callers still use BUG_ON()) Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com --- fs/btrfs/ctree.c |3 ++- fs/btrfs/disk-io.c |5 - fs/btrfs/extent-tree.c | 25 ++--- fs/btrfs/file-item.c

read-only subvolumes?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, When I am creating subvolumes I get this strange behavior. If I create a subvolume with a name longer than 4 characters it is read-only, if the name is shorter than 5 characters the subvolume is writeable as expected. I think it is since I

Re: read-only subvolumes?

On Wed, Mar 23, 2011 at 3:21 PM, Andreas Philipp philipp.andr...@gmail.com wrote: I think it is since I upgraded to kernel version 2.6.38 (I do not create subvolumes on a regular basis.). thor btrfs # btrfs subvolume create 123456789 Create subvolume './123456789' thor btrfs # touch

Re: read-only subvolumes?

Hi all, When I am creating subvolumes I get this strange behavior. If I create a subvolume with a name longer than 4 characters it is read-only, if the name is shorter than 5 characters the subvolume is writeable as expected. I think it is since I upgraded to kernel version 2.6.38 (I do

Re: [PATCH V4] btrfs: implement delayed inode items operation

Hi, Kitayama-san On wed, 23 Mar 2011 13:19:18 +0900, Itaru Kitayama wrote: On Wed, 23 Mar 2011 12:00:38 +0800 Miao Xie mi...@cn.fujitsu.com wrote: I is testing the new version, in which I fixed the slab shrinker problem reported by Chris. In the new version, the delayed node is removed

Re: read-only subvolumes?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23.03.2011 10:25, Li Zefan wrote: Hi all, When I am creating subvolumes I get this strange behavior. If I create a subvolume with a name longer than 4 characters it is read-only, if the name is shorter than 5 characters the subvolume is

Re: [PATCH] btrfs scrub: make fixups sync, don't reuse fixup bios

Hi Ilya, On 18.03.2011 17:21, Ilya Dryomov wrote: [CC'ing the list to make development public, the patch is againt Arne's tree at kernel.org] Below is a quite long diff the primary purpose of which is to make fixups totally sync. They are already sync for checksum failures, this patch

Re: read-only subvolumes?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23.03.2011 11:07, Andreas Philipp wrote: On 23.03.2011 10:25, Li Zefan wrote: Hi all, When I am creating subvolumes I get this strange behavior. If I create a subvolume with a name longer than 4 characters it is read-only, if the name is

Re: [PATCH RFC] btrfs: Simplify locking

Hello, Chris. On Tue, Mar 22, 2011 at 07:13:09PM -0400, Chris Mason wrote: Ok, this impact of this is really interesting. If we have very short waits where there is no IO at all, this patch tends to lose. I ran with dbench 10 and got about 20% slower tput. But, if we do any IO at all it

Re: [PATCH RFC] btrfs: Simplify locking

Excerpts from Tejun Heo's message of 2011-03-23 06:46:14 -0400: Hello, Chris. On Tue, Mar 22, 2011 at 07:13:09PM -0400, Chris Mason wrote: Ok, this impact of this is really interesting. If we have very short waits where there is no IO at all, this patch tends to lose. I ran with dbench

Re: efficiency of btrfs cow

On 11-03-06 11:06 AM, Calvin Walton wrote: To see exactly what's going on, you should use the btrfs filesystem df command to see how space is being allocated for data and metadata separately: OK. So with an empty filesystem, before my first copy (i.e. the base on which the next copy will

[RFC] Tree fragmentation and prefetching

While looking into the performance of scrub I noticed that a significant amount of time is being used for loading the extent tree and the csum tree. While this is no surprise I did some prototyping on how to improve on it. The main idea is to load the tree (or parts of it) top-down, order the

Re: [PATCH V4] btrfs: implement delayed inode items operation

On wed, 23 Mar 2011 09:57:56 +0800, Miao Xie wrote: On Mon, 21 Mar 2011 08:08:17 -0400, Chris Mason wrote: I also think that code is racing with the code that frees delayed nodes, but haven't yet triggered my debugging printks to prove either one. We free delayed nodes when we want to destroy

Re: [PATCH v2 3/6] btrfs: add scrub code and prototypes

On 22.03.2011 17:38, David Sterba wrote: David Sterba wrote: On Fri, Mar 11, 2011 at 03:49:40PM +0100, Arne Jansen wrote: This is the main scrub code. sizeof(struct scrub_dev) == 18760 on an x86_64, an order 3 allocation in scrub_setup_dev() Is this a problem? There are only few

Re: [RFC] Tree fragmentation and prefetching

On 23.03.2011 14:06, Arne Jansen wrote: While looking into the performance of scrub I noticed that a significant amount of time is being used for loading the extent tree and the csum tree. While this is no surprise I did some prototyping on how to improve on it. The main idea is to load the

[RFC PATCH] mutex: Apply adaptive spinning on mutex_trylock()

Hello, guys. I've been playing with locking in btrfs which has developed custom locking to avoid excessive context switches in its btree implementation. Generally, doing away with the custom implementation and just using the mutex adaptive owner spinning seems better; however, there's an

Re: [RFC PATCH] mutex: Apply adaptive spinning on mutex_trylock()

On Wed, Mar 23, 2011 at 8:37 AM, Tejun Heo t...@kernel.org wrote: Currently, mutex_trylock() doesn't use adaptive spinning.  It tries just once.  I got curious whether using adaptive spinning on mutex_trylock() would be beneficial and it seems so, at least for btrfs anyway. Hmm. Seems

Re: [RFC PATCH] mutex: Apply adaptive spinning on mutex_trylock()

On Wed, Mar 23, 2011 at 08:48:01AM -0700, Linus Torvalds wrote: On Wed, Mar 23, 2011 at 8:37 AM, Tejun Heo t...@kernel.org wrote: Currently, mutex_trylock() doesn't use adaptive spinning.  It tries just once.  I got curious whether using adaptive spinning on mutex_trylock() would be

Re: efficiency of btrfs cow

I'm not a developer, but I think it goes something like this: btrfs doesn't write the filesystem on the entire device/partition at format time, rather, it dynamically increases the size of the filesystem as data is used. That's why formating a disk in btrfs can be so fast. On Wed, Mar 23, 2011 at

Re: efficiency of btrfs cow

On 11-03-23 11:53 AM, Chester wrote: I'm not a developer, but I think it goes something like this: btrfs doesn't write the filesystem on the entire device/partition at format time, rather, it dynamically increases the size of the filesystem as data is used. That's why formating a disk in btrfs

stratified B-trees

I just noticed this out today on the arXiv : http://xxx.lanl.gov/abs/1103.4282 The paper describes stratified B-trees and quoting from the abstract: We describe the `stratified B-tree', which beats the CoW B-tree in every way. In particular, it is the first versioned dictionary to achieve

Re: [PATCH v4 3/6] btrfs: add scrub code and prototypes

Hi, I'm reviewing the atomic counters and the wait/wake infrastructure, just found two missed mutex_unlock()s in btrfs_scrub_dev() in error paths. On Fri, Mar 18, 2011 at 04:55:06PM +0100, Arne Jansen wrote: This is the main scrub code. Updates v3: - fixed EIO handling, need to

Re: [PATCH v4 4/6] btrfs: sync scrub with commit device removal

Hi, you are adding a new smp_mb, can you please explain why it's needed and document it? thanks, dave On Fri, Mar 18, 2011 at 04:55:07PM +0100, Arne Jansen wrote: This adds several synchronizations: - for a transaction commit, the scrub gets paused before the tree roots are committed

Re: efficiency of btrfs cow

So it's clear that total usage (as reported by df) was 121,402,328KB but Metadata has two values: Metadata: total=5.01GB, used=3.26GB What's the difference between total and used?  And for that matter, what's the difference between the total and used for Data (total=110.01GB,

Re: stratified B-trees

Karn Kallio tierplusplusli...@gmail.com writes: Are these stratified B-trees something which the btrfs project could use? The current b*tree is pretty much hardcoded in the disk format, so it would be hard to change in a compatible way. -Andi -- a...@linux.intel.com -- Speaking for myself

Re: stratified B-trees

On Wed, Mar 23, 2011 at 5:38 PM, Karn Kallio tierplusplusli...@gmail.com wrote: I just noticed this out today on the arXiv : http://xxx.lanl.gov/abs/1103.4282 The paper describes stratified B-trees and quoting from the abstract: LOL. It looks like this paper is generated by a robot: ...

Btrfs wins Linux New Media Award

Hi everyone, During the last Cebit conference, Btrfs was presented with an award for the most innovative open source project. I'd like to thank everyone at Linux magazine involved with selecting us, and since we have so many contributors I wanted to share a picture of the shiny award:

Recovering parent transid verify failed

Hi, I'm having the same issues as previously mentioned. Apparently the new fsck tool will be able to recover this? Few questions, is there a GIT version I can compile and use already for this? If not, is there any indication of when this will be released? --- Luke Sheldrick e:

Re: [RFC] Tree fragmentation and prefetching

On Wed, Mar 23, 2011 at 4:06 PM, Arne Jansen sensi...@gmx.net wrote: While looking into the performance of scrub I noticed that a significant amount of time is being used for loading the extent tree and the csum tree. While this is no surprise I did some prototyping on how to improve on it.

Re: [RFC] Tree fragmentation and prefetching

Excerpts from Arne Jansen's message of 2011-03-23 09:06:02 -0400: While looking into the performance of scrub I noticed that a significant amount of time is being used for loading the extent tree and the csum tree. While this is no surprise I did some prototyping on how to improve on it. The

Re: [RFC PATCH] mutex: Apply adaptive spinning on mutex_trylock()

On Wed, Mar 23, 2011 at 6:48 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Mar 23, 2011 at 8:37 AM, Tejun Heo t...@kernel.org wrote: Currently, mutex_trylock() doesn't use adaptive spinning.  It tries just once.  I got curious whether using adaptive spinning on

Re: [RFC] Tree fragmentation and prefetching

On 23.03.2011 20:26, Andrey Kuzmin wrote: On Wed, Mar 23, 2011 at 4:06 PM, Arne Jansensensi...@gmx.net wrote: While looking into the performance of scrub I noticed that a significant amount of time is being used for loading the extent tree and the csum tree. While this is no surprise I did

Re: [RFC] Tree fragmentation and prefetching

On Wed, Mar 23, 2011 at 11:28 PM, Arne Jansen sensi...@gmx.net wrote: On 23.03.2011 20:26, Andrey Kuzmin wrote: On Wed, Mar 23, 2011 at 4:06 PM, Arne Jansensensi...@gmx.net  wrote: While looking into the performance of scrub I noticed that a significant amount of time is being used for

Re: Recovering parent transid verify failed

Excerpts from Luke Sheldrick's message of 2011-03-23 14:12:45 -0400: Hi, I'm having the same issues as previously mentioned. Apparently the new fsck tool will be able to recover this? Few questions, is there a GIT version I can compile and use already for this? If not, is there any

Re: Btrfs wins Linux New Media Award

On 03/23/2011 02:17 PM, Chris Mason wrote: Hi everyone, During the last Cebit conference, Btrfs was presented with an award for the most innovative open source project. I'd like to thank everyone at Linux magazine involved with selecting us, and since we have so many contributors I wanted to

Re: [RFC] Tree fragmentation and prefetching

On wed, 23 Mar 2011 21:28:25 +0100, Arne Jansen wrote: On 23.03.2011 20:26, Andrey Kuzmin wrote: On Wed, Mar 23, 2011 at 4:06 PM, Arne Jansensensi...@gmx.net wrote: While looking into the performance of scrub I noticed that a significant amount of time is being used for loading the extent

Re: [PATCH V4] btrfs: implement delayed inode items operation

On Wed, 23 Mar 2011 17:47:01 +0800 Miao Xie mi...@cn.fujitsu.com wrote: we found GFP_KERNEL was passed into kzalloc(), I think this flag trigger the above lockdep warning. the attached patch, which against the delayed items operation patch, may fix this problem, Could you test it for me?