Re: [PATCH] Btrfs: use do_div to avoid compile errors on 32bit box

2011-08-19 Thread liubo
I just sent a wrong version. Plz ignore this one. I'm sorry. thanks, liubo > Signed-off-by: Liu Bo > --- > fs/btrfs/extent-tree.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c > index 80d

Re: [PATCH] Btrfs: use do_div to avoid compile errors on 32bit box

2011-08-19 Thread liubo
; [fs/btrfs/btrfs.ko] undefined! >> make[1]: *** [__modpost] Error 1 >> >> Signed-off-by: Liu Bo > > Chris just left for vacation, can you send this to Linus/lkml so it gets > pulled > in. Thanks, > Already done. thanks, liubo > Josef > -- > To unsubscribe f

Re: [PATCH] Btrfs: check if there is enough space for balancing smarter

2011-08-18 Thread liubo
->rw_devices; >> +min_free /= dev_min; > ^^^ > > 64bit division will break 32bit builds, can you please convert it to > do_div ? the other is 'div-by-power-of-2' which will most probably be > converted to shifts. > This

Re: [PATCH] Btrfs: fix an oops of log replay

2011-08-16 Thread liubo
1 files changed, 24 insertions(+), 4 deletions(-) > > This fixes the oops for me. The bug was a regression in 2.6.39, I believe. > > Tested-by: Andy Lutomirski > Thanks a lot for testing! thanks, liubo > --Andy > -- > To unsubscribe from this list: send the line "un

Re: [GIT PULL v3] Btrfs: improve write ahead log with sub transaction

2011-08-06 Thread liubo
On 08/06/2011 11:44 AM, liubo wrote: > Hi, Chris, > > On 08/04/2011 09:57 PM, Chris Mason wrote: >> Excerpts from Liu Bo's message of 2011-06-21 04:49:41 -0400: >>> I've been working to try to improve the write-ahead log's performance, >>> and I fou

Re: [GIT PULL v3] Btrfs: improve write ahead log with sub transaction

2011-08-05 Thread liubo
_kern_mount+0x63/0xd0 [] do_kern_mount+0x52/0x110 [] ? security_capable+0x2a/0x30 [] do_mount+0x257/0x7e0 [] ? memdup_user+0x4b/0x90 [] ? strndup_user+0x5b/0x80 [] sys_mount+0x90/0xe0 [] system_call_fastpath+0x16/0x1b thanks, liubo > -chris > >> Then a idea for this suggested by Chris

Re: [PATCH] Btrfs: skip looking for delalloc if we don't have ->fill_delalloc

2011-08-01 Thread liubo
On 08/02/2011 09:32 AM, liubo wrote: > On 08/02/2011 12:11 AM, Josef Bacik wrote: >> We always look for delalloc bytes in our io_tree so we can fill in delalloc. >> This is fine in most cases, but if we're writing out the btree_inode this is >> just a superfluous tree sea

Re: [PATCH] Btrfs: skip looking for delalloc if we don't have ->fill_delalloc

2011-08-01 Thread liubo
0 00 00 4c 89 fa 4c 89 e6 e8 19 cf 01 00 eb bd <0f> 0b eb fe 48 89 df e8 1b 48 b6 e0 eb 9d 66 0f 1f 84 00 00 00 RIP [] btrfs_writepage_fixup_worker+0x139/0x150 [btrfs] RSP ---[ end trace 5089b598ce74fcfc ]--- thanks, liubo -- To unsubscribe from this list: send the line "un

Re: kernel BUG at fs/btrfs/tree-log.c:1669!

2011-07-27 Thread liubo
ixed groups, you may go to btrfs-unstable source's ctree.h to get real BTRFS_FEATURE_INCOMPAT_SUPP and update btrfs-progs side, then work it out. :) thanks, liubo -- 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] Btrfs: fix oops while writing data to SSD partitions

2011-07-27 Thread liubo
On 07/27/2011 10:26 PM, Josef Bacik wrote: > On 07/27/2011 05:49 AM, liubo wrote: >> Here I have a two SSD-partitions btrfs, and they are defaultly set to >> "data=raid0, metadata=raid1", then I try to fill my btrfs partition >> till "No space left on device&

[PATCH] Btrfs: fix oops while writing data to SSD partitions

2011-07-27 Thread liubo
Here I have a two SSD-partitions btrfs, and they are defaultly set to "data=raid0, metadata=raid1", then I try to fill my btrfs partition till "No space left on device", via "dd if=/dev/zero of=/mnt/btrfs/tmp". I get an oops panic from kernel BUG at fs/btrfs/extent-tree.c:5199!, which refers to fi

Re: [PATCH] Btrfs: don't be as agressive with delalloc metadata reservations

2011-07-17 Thread liubo
3c/0x1c0 [] sys_umount+0x7b/0x3a0 [] system_call_fastpath+0x16/0x1b ---[ end trace 9a65800674b03b84 ]--- thanks, liubo > Signed-off-by: Josef Bacik > --- > fs/btrfs/ctree.c | 10 +- > fs/btrfs/ctree.h |5 ++--- > fs/btrfs/disk-io.c |3 ++-

Re: [PATCH] Btrfs: fix deadlock when throttling transactions

2011-07-14 Thread liubo
t) { > spin_unlock(&cur_trans->commit_lock); > atomic_inc(&cur_trans->use_count); > - btrfs_end_transaction(trans, root); > + __btrfs_end_transaction(trans, root, 0, 1); > Looks good. BTW, btrfs_end_transaction(tran

Re: [GIT PULL v4] Btrfs: improve write ahead log with sub transaction

2011-06-30 Thread liubo
> merging > in the new extents from the file. > > This patchset puts the above idea into code, and although the code is now more > complex, it brings us a great deal of performance improvement: > This is also available in git://repo.or.cz/linux-btrfs-devel.git sub-trans

Re: [PATCH 1/2 v2] Btrfs: kill location key of in-memory inode

2011-06-27 Thread liubo
ping? On 06/20/2011 10:59 AM, Liu Bo wrote: > In btrfs's in-memory inode, there is a btrfs_key which has the structure: > - key.objectid > - key.type > - key.offset > > however, we only use key.objectid to search, to check or something else, > and to reduce in-memory inode size I just keep what i

Re: [PATCH 10/12 v3] Btrfs: deal with EEXIST after iput

2011-06-21 Thread liubo
logged but the transaction has not yet been committed in > btrfs_drop_inode? That way the inode doesn't get evicted from cache > until after we know it's ok and that way we don't have to waste a tree > lookup. Thanks, > Good idea, I'll follow it. thanks, liubo > J

Re: [PATCH 1/2] Btrfs: kill location key of in-memory inode

2011-06-19 Thread liubo
t; +BTRFS_I(inode)->inode_id = key->objectid; > > memcpy -> direct assignment > >> BTRFS_I(inode)->dummy_inode = 1; >> >> inode->i_ino = BTRFS_EMPTY_SUBVOL_DIR_OBJECTID; >> @@ -4417,7 +4432,6 @@ static struct inode *btrfs_new_inode(struct >&

Re: [PATCH 00/11 v2] Btrfs: improve write ahead log with sub transaction

2011-06-09 Thread liubo
ion. Yea, I've noticed the trans_mutex thing, but I'm afraid I have to do this till next week, cause these is a "btrfs fi bal" bug still on going on my schedule. thanks, liubo > > thanks, > david > -- > To unsubscribe from this list: send the line &quo

[PATCH] Btrfs: check root_key's offset instead

2011-06-08 Thread liubo
When we use reloc root to cow or copy a tree block, we do not set the block's owner, instead we set its header's flag with BTRFS_HEADER_FLAG_RELOC. So here we should check for root_key's offset. Signed-off-by: Liu Bo --- fs/btrfs/extent-tree.c |2 +- 1 files changed, 1 insertions(+), 1 dele

Re: kernel BUG at fs/btrfs/extent-tree.c:6164!

2011-06-07 Thread liubo
On 06/07/2011 04:24 PM, Tsutomu Itoh wrote: > (2011/06/07 15:17), Tsutomu Itoh wrote: >> (2011/06/07 14:59), Tsutomu Itoh wrote: >>> Hi liubo, >>> >>> (2011/06/07 14:31), liubo wrote: >>>> On 06/06/2011 04:33 PM, Tsutomu Itoh wrote: >>>>

Re: kernel BUG at fs/btrfs/extent-tree.c:6164!

2011-06-06 Thread liubo
Author: David Sterba Date: Fri Jun 3 16:29:08 2011 +0200 btrfs: fix uninitialized variable warning and tried on 1) a single disk, 2) 2 disks and 3) 4 disks respectively, but none of them leaded to the below bug. I guess

Re: btrfs error after using kernel 3.0-rc1

2011-06-01 Thread liubo
the files somewhere else before reinstalling this > system. > > On another note, does anybody know how btrfs allocates ID for subvols? > It doesn't seem to reuse deleted subvol's ID. What happens when the > last subvol ID is 999? > Yes, no reuse. a new subvol will be 1000, one large than 999. thanks, liubo -- 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: [3.0-rc1] kernel BUG at fs/btrfs/relocation.c:4285!

2011-06-01 Thread liubo
On 06/01/2011 04:12 PM, liubo wrote: > On 06/01/2011 03:44 PM, liubo wrote: >> > On 05/31/2011 08:27 AM, Tsutomu Itoh wrote: >>>> >> > The panic occurred when 'btrfs fi bal /test5' was executed. >>>> >> > >>>> >&g

Re: [3.0-rc1] kernel BUG at fs/btrfs/relocation.c:4285!

2011-06-01 Thread liubo
On 06/01/2011 03:44 PM, liubo wrote: > On 05/31/2011 08:27 AM, Tsutomu Itoh wrote: >> > The panic occurred when 'btrfs fi bal /test5' was executed. >> > >> > /test5 is as follows: >> > # mount -o space_cache,compress=lzo /dev/sdc3 /test5 >>

Re: [3.0-rc1] kernel BUG at fs/btrfs/relocation.c:4285!

2011-06-01 Thread liubo
t_key.objectid < BTRFS_FIRST_FREE_OBJECTID) + return 0; + path = btrfs_alloc_path(); if (!path) return -ENOMEM; thanks, liubo > --- > Tsutomu > > > > <6>device fsid

Re: [3.0-rc1] kernel BUG at fs/btrfs/relocation.c:4285!

2011-05-30 Thread liubo
the filesystem to recreate this? > > Yes, I have. > In my test, the panic is done at frequency once every about ten times. > > I attached the test script to this mail. (though it is a dirty test script > that scrapes up script...) > I'm getting it to run, hope we can g

Re: [PATCH 00/11 v2] Btrfs: improve write ahead log with sub transaction

2011-05-26 Thread liubo
This includes the two patches that we've discussed before. I sent this as a whole just in case you have to patch the code by yourself. :) thanks, liubo On 05/26/2011 04:19 PM, Liu Bo wrote: > I've been working to try to improve the write-ahead log's performance, >

Re: Backref walking utilities

2011-05-25 Thread liubo
On 05/25/2011 11:08 PM, Jan Schmidt wrote: > On 05/23/2011 12:02 PM, Arne Jansen wrote: >> Hi liubo, >> >> On 23.05.2011 11:53, liubo wrote: >>> As one of my plans, I'm going to take this project over unless someone has >>> been working on it. >&

Re: [PATCH 1/2] tracing: add __print_symbolic_u64 to avoid warnings on 32bit machine

2011-05-24 Thread liubo
On 05/01/2011 11:35 AM, Steven Rostedt wrote: > On Fri, 2011-04-29 at 18:01 +0800, liubo wrote: >> ping? > > Sorry, I've been trying to get the new ftrace function tracer features > out ASAP. I plan on looking at this when I'm done. > > Thanks, > Hi, St

Re: [PATCH 1/9] Btrfs: introduce sub transaction stuff

2011-05-24 Thread liubo
On 05/24/2011 11:56 PM, liubo wrote: >> > >> > Second, we use the generation number of the super to read in the log >> > tree root after a crash. This doesn't always match the sub trans id and >> > so it doesn't always match the transid stored i

Re: [PATCH 1/9] Btrfs: introduce sub transaction stuff

2011-05-24 Thread liubo
On 05/24/2011 11:56 PM, liubo wrote: >> > The problems I hit: >> > >> > When an inode is dropped from cache (just via iput) and then read in >> > again, the BTRFS_I(inode)->logged_trans goes back to zero. When this >> > happens the logging

Re: [PATCH v1 2/5] btrfs: state information for readahead

2011-05-23 Thread liubo
t;device_list_mutex); > diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h > index cc2eada..33acd4e 100644 > --- a/fs/btrfs/volumes.h > +++ b/fs/btrfs/volumes.h > @@ -86,6 +86,14 @@ struct btrfs_device { > u8 uuid[BTRFS_UUID_SIZE]; > > struct btrfs_work w

Re: [PATCH 1/9] Btrfs: introduce sub transaction stuff

2011-05-23 Thread liubo
est given that we can now reuse > inode numbers. > > Second, we use the generation number of the super to read in the log > tree root after a crash. This doesn't always match the sub trans id and > so it doesn't always match the transid stored in the btree blocks. > > T

Re: [PATCH 0/9] Btrfs: improve write ahead log with sub transaction

2011-05-23 Thread liubo
ad 0b Written 39.062Mb Total transferred 39.062Mb >> === >> a) without patch: (*SPEED* : 451.01Kb/sec) >>112.75 Requests/sec executed >> >> b) with patch: (*SPEED* : 4.3621Mb/sec) >>1116.71 Requests/sec executed >> > > Have you run

Backref walking utilities

2011-05-23 Thread liubo
I miss or misunderstand something? Any comments are welcomed. :) thanks, liubo -- 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/9] Btrfs: introduce sub transaction stuff

2011-05-19 Thread liubo
it. > > Thanks! > It's so great that you like it. :) But I must NOTE again: Due to the bug which patch 8 fixed, the previous preformance statistics I posted sometime ago, like (*SPEED* : 4.7+ Mb/sec), are valueless and cannot be used as a basis any more... Hope that more people can get the patchset tested. thanks, liubo > -chris > -- 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 0/9] Btrfs: improve write ahead log with sub transaction

2011-05-19 Thread liubo
On 05/19/2011 04:11 PM, Liu Bo wrote: > I've been working to try to improve the write-ahead log's performance, > and I found that the bottleneck addresses in the checksum items, > especially when we want to make a random write on a large file, e.g a 4G file. > > Then a idea for this suggested by C

Re: crash in btrfsck, btrfs-debug-tree, etc

2011-05-16 Thread liubo
odate(eb); + if (ret == 0) return eb; - } num_copies = btrfs_num_copies(&root->fs_info->mapping_tree, eb->start, eb->len); if (num_copies == 1) { thanks, liubo. > Unfo

[RFC PATCH] Btrfs: do not flush csum items of unchanged file data during treelog

2011-05-05 Thread liubo
The current code relogs the entire inode every time during fsync log, and it is much better suited to small files rather than large ones. During my performance test, the fsync performace of large files sucks, and we can ascribe this to the tremendous amount of csum infos of the large ones, cause

Re: [PATCH] btrfs progs: fix extra metadata chunk allocation in --mixed case

2011-05-05 Thread liubo
On 05/05/2011 10:16 PM, Arne Jansen wrote: > When creating a mixed fs with mkfs, an extra metadata chunk got allocated. > This is because btrfs_reserve_extent calls do_chunk_alloc for METADATA, > which in turn wasn't able to find the proper space_info, as __find_space_info > did a hard compare of t

Re: [PATCH 1/2] tracing: add __print_symbolic_u64 to avoid warnings on 32bit machine

2011-04-29 Thread liubo
ping? On 04/19/2011 09:35 AM, liubo wrote: > Filesystem, like Btrfs, has some "ULL" macros, and when these macros are > passed > to tracepoints'__print_symbolic(), there will be 64->32 truncate WARNINGS > during > compiling on 32bit box. > > Signed

Re: [RFC PATCH] Btrfs: do not flush csum items of unchanged file data during treelog

2011-04-25 Thread liubo
t; Right, at the very least we want to just use one bit of that field > instead of all 8. But keeping a sub-transid and putting that in the > generation field of the file extent instead can get us the same benefits > without stealing the bits. > Nice. This is the first step of my

[RFC PATCH] Btrfs: do not flush csum items of unchanged file data during treelog

2011-04-21 Thread liubo
The current code relogs the entire inode every time during fsync log, and it is much better suited to small files rather than large ones. During my performance test, the fsync performace of large files sucks, and we can ascribe this to the tremendous amount of csum infos of the large ones, cause

Re: [PATCH 1/1] btrfs: add missing spin_unlock to a rare exit path

2011-04-20 Thread liubo
Good catch! thanks, liubo On 04/20/2011 08:34 PM, David Sterba wrote: > Signed-off-by: David Sterba > --- > fs/btrfs/disk-io.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c > index 5e5d07c..25e4b8f 10

[PATCH 1/2] tracing: add __print_symbolic_u64 to avoid warnings on 32bit machine

2011-04-18 Thread liubo
Filesystem, like Btrfs, has some "ULL" macros, and when these macros are passed to tracepoints'__print_symbolic(), there will be 64->32 truncate WARNINGS during compiling on 32bit box. Signed-off-by: Liu Bo --- include/linux/ftrace_event.h | 12 include/trace/ftrace.h | 1

[PATCH 2/2] tracing: update btrfs's tracepoints to use u64 interface

2011-04-18 Thread liubo
To avoid 64->32 truncating WARNING, update btrfs's tracepoints. Signed-off-by: Liu Bo --- include/trace/events/btrfs.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/trace/events/btrfs.h b/include/trace/events/btrfs.h index f445cff..4114129 100644 --- a/incl

Re: [PATCH] Trace: add __print_symbolic_u64 to avoid warnings on 32bit machine

2011-04-18 Thread liubo
On 04/19/2011 02:11 AM, Steven Rostedt wrote: > On Wed, 2011-04-06 at 17:18 +0800, liubo wrote: >> Btrfs has some "ULL" macros, and when these macros are passed to tracepoints' >> __print_symbolic(), there will be 64->32 truncate WARNINGS during compiling >>

Re: [PATCH 1/2] E2fsprogs: use the generic inode flags

2011-04-18 Thread liubo
On 04/18/2011 04:41 PM, Coly Li wrote: > On 2011年04月18日 15:37, liubo Wrote: >> Signed-off-by: Liu Bo >> --- >> debugfs/htree.c|2 +- >> e2fsck/pass1.c | 22 +++--- >> e2fsck/pass2.c |2 +- >> e2fsck/pass4.

[PATCH 2/2] E2fsprogs: add compress and cow support in chattr, lsattr

2011-04-18 Thread liubo
Modify command 'chattr' and 'lsattr' to support compress and cow. - use 'C' to indicate NOCOW attribute. - still use 'c' to indicate compress attribute. Also update the man doc. Signed-off-by: Liu Bo --- lib/e2p/pf.c |1 + lib/ext2fs/ext2_fs.h |1 + misc/chattr.1.in | 15 +

[PATCH 1/2] E2fsprogs: use the generic inode flags

2011-04-18 Thread liubo
Signed-off-by: Liu Bo --- debugfs/htree.c|2 +- e2fsck/pass1.c | 22 +++--- e2fsck/pass2.c |2 +- e2fsck/pass4.c |2 +- e2fsck/rehash.c|4 ++-- ext2ed/inode_com.c | 14 +++--- lib/e2p/fgetflags.c|6 ++

Re: [RFC] Add a new file op for fsync to give fs's more control

2011-04-17 Thread liubo
g to improve the fsync performance stuff, but mainly for large files(>4G). And I found that a large file will have a tremendous amount of csum items needed to be flush into tree log during fsync(). Btrfs now uses a brute force approach to ensure to get the most uptodate copies of everything, an

Re: [PATCH] Btrfs: avoid taking the chunk_mutex in do_chunk_alloc V2

2011-04-12 Thread liubo
On 04/12/2011 08:55 PM, Josef Bacik wrote: > Everytime we try to allocate disk space we try and see if we can pre-emptively > allocate a chunk, but in the common case we don't allocate anything, so there > is > no sense in taking the chunk_mutex at all. So instead if we are allocating a > chunk,

Re: [PATCH] Btrfs: avoid taking the chunk_mutex in do_chunk_alloc

2011-04-11 Thread liubo
: > spin_lock(&space_info->lock); > if (space_info->force_alloc) > force = 1; > @@ -3299,9 +3300,27 @@ static int do_chunk_alloc(struct btrfs_trans_handle > *trans, > alloc_bytes)) { > spi

Re: [PATCH] Btrfs: fix easily get into ENOSPC in mixed case

2011-04-10 Thread liubo
g, though. I guess something messed up your btrfs metadata, cause when btrfs_unlink() wanted to remove A, it found that A was just missing... thanks, liubo -- 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

[PATCH] Btrfs: fix easily get into ENOSPC in mixed case

2011-04-08 Thread liubo
When a btrfs disk is created by mixed data & metadata option, it will have no pure data or pure metadata space info. In btrfs's for-linus branch, commit 78b1ea13838039cd88afdd62519b40b344d6c920 (Btrfs: fix OOPS of empty filesystem after balance) initializes space infos at the very beginning. The

Re: [PATCH] Btrfs-progs: add support for mixed data+metadata block groups

2011-04-08 Thread liubo
th 8388608 owner 2 type 4 num_stripes 1 <== stripe 0 devid 1 offset 12582912 <== === you see, there exists another metadata chunk (type 4) after "mkfs.btrfs -M /dev/xxx". So I was wondering that _IS_ this chunk

[PATCH] Trace: add __print_symbolic_u64 to avoid warnings on 32bit machine

2011-04-06 Thread liubo
Btrfs has some "ULL" macros, and when these macros are passed to tracepoints' __print_symbolic(), there will be 64->32 truncate WARNINGS during compiling on 32bit box. Signed-off-by: Liu Bo --- include/linux/ftrace_event.h | 12 include/trace/events/btrfs.h |4 ++-- include/t

Re: [PATCH 2/2 v2] Btrfs: Per file/directory controls for COW and compression

2011-04-05 Thread liubo
> folder(force-compress would be ideal) of a large btrfs volume, and > disabling it for the rest. > hmm, I'm making the tool's patch, and will come soon. :) > > On 21/3/2011 10:57 πμ, liubo wrote: >> Data compression and data cow are controlled across the entire FS

Re: 2.6.39-rc1: kernel BUG at fs/btrfs/extent-tree.c:5479!

2011-04-02 Thread liubo
On 04/02/2011 06:41 PM, Sergei Trofimovich wrote: > On Sat, 02 Apr 2011 17:37:58 +0800 > liubo wrote: > >> On 04/02/2011 05:19 PM, Sergei Trofimovich wrote: >>> The partition is a physical ~5GB --mixed lzo compressed partition. >>> >>&g

Re: 2.6.39-rc1: kernel BUG at fs/btrfs/extent-tree.c:5479!

2011-04-02 Thread liubo
83.html) > Hi, Sergei, I'm digging this... Can u show me steps to reproduce this? thanks, liubo > This time I've really filled whole partition and kernel OOpsed. > Note, the blow came right after INFO about hung write task (see full dmesg), > so it could be bad guy. > >

Re: [RFC PATCH] Trace: use unsigned long long in trace print frames

2011-04-01 Thread liubo
On 04/01/2011 09:49 PM, Steven Rostedt wrote: > On Fri, 2011-04-01 at 14:42 +0800, liubo wrote: >> While adding tracepoint for btrfs, I got a problem: >> >> btrfs uses some macros with "ULL" type, but tracepoint's macros, >> __print_[flags,symbols](),

[RFC PATCH] Trace: use unsigned long long in trace print frames

2011-03-31 Thread liubo
While adding tracepoint for btrfs, I got a problem: btrfs uses some macros with "ULL" type, but tracepoint's macros, __print_[flags,symbols](), only have "unsigned long", so on 32bit box there will be 64->32 truncate WARNINGs when compiling. Here I'm inclined to make the replacement to clear tho

Re: [PATCH 1/2] Btrfs: fix OOPS of empty filesystem after balance

2011-03-31 Thread liubo
On 03/30/2011 07:58 PM, Arne Jansen wrote: > Am 10.03.2011 13:28, schrieb Chris Mason: >> Excerpts from liubo's message of 2011-03-10 03:50:27 -0500: >>> On 03/07/2011 10:13 AM, liubo wrote: >>>> btrfs will remove unused block groups after balance. >>&g

Re: [PATCH] Btrfs: fix compile warning from __btrfs_map_block

2011-03-31 Thread liubo
sed the for-linus and > for-linus-unmerged branch to get rid of it. > > Sorry for the confusion. Ah, it is my fault to neglect the version, I found this warning while compiling the latest for-linus tree (top commit: c1e1f82c56af1a286fd747e809c94628c2ca15fb). thanks, liubo > > -chris

[PATCH] btrfs: clear __GFP_FS flag in the space cache inode

2011-03-31 Thread liubo
From: Miao Xie the object id of the space cache inode's key is allocated from the relative root, just like the regular file. So we can't identify space cache inode by checking the object id of the inode's key, and we have to clear __GFP_FS flag at the time we look up the space cache inode. Signe

[PATCH] Btrfs: fix compile warning from __btrfs_map_block

2011-03-31 Thread liubo
While compile btrfs modules on 32bit box, I encounter the following: WARNING: "__umoddi3" [fs/btrfs/btrfs.ko] undefined! The WARNING comes from that __btrfs_map_block does not use do_div() for relative operations, this will cause problems on 32bit box, for values with "u64" type should use do_di

Re: [PATCH] Btrfs: add initial tracepoint support for btrfs

2011-03-29 Thread liubo
Please ignore this patch... I just found we'd better revise the tracepoint side instead of btrfs side, will dig it more. thanks, liubo > From: Liu Bo > > [PATCH] Btrfs: fix compile warnings of btrfs tracepoint on 32bit box > > include/trace/events/btrfs.h:47:1: wa

Re: [PATCH] Btrfs: add initial tracepoint support for btrfs

2011-03-29 Thread liubo
On 03/29/2011 09:16 AM, liubo wrote: > On 03/28/2011 08:59 AM, Chris Mason wrote: >> Excerpts from Chris Mason's message of 2011-03-26 08:12:04 -0400: >>> Excerpts from liubo's message of 2011-03-24 07:18:59 -0400: >>>> Tracepoints can provide insight

Re: [PATCH] Btrfs: add initial tracepoint support for btrfs

2011-03-28 Thread liubo
y > truncated to unsigned type > Ahh, I figure it out. Will send a new version to clear warnings. Thanks, liubo > -chris > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More ma

[PATCH] Btrfs: add initial tracepoint support for btrfs

2011-03-24 Thread liubo
Tracepoints can provide insight into why btrfs hits bugs and be greatly helpful for debugging, e.g dd-7822 [000] 2121.641088: btrfs_inode_request: root = 5(FS_TREE), gen = 4, ino = 256, blocks = 8, disk_i_size = 0, last_trans = 8, logged_trans = 0 dd-7822 [000] 21

[PATCH 2/2 v3] Btrfs: Per file/directory controls for COW and compression

2011-03-22 Thread liubo
From: Liu Bo Subject: [PATCH 2/2 v3] Btrfs: Per file/directory controls for COW and compression Data compression and data cow are controlled across the entire FS by mount options right now. ioctls are needed to set this on a per file or per directory basis. This has been proposed previously,

Re: [PATCH 2/2 v2] Btrfs: Per file/directory controls for COW and compression

2011-03-21 Thread liubo
On 03/22/2011 01:43 AM, Johann Lombardi wrote: > On Mon, Mar 21, 2011 at 04:57:13PM +0800, liubo wrote: >> @@ -4581,8 +4583,6 @@ static struct inode *btrfs_new_inode(struct >> btrfs_trans_handle *trans, >> location->offset = 0; >> btrfs_set_key_type(

[PATCH 2/2 v2] Btrfs: Per file/directory controls for COW and compression

2011-03-21 Thread liubo
Data compression and data cow are controlled across the entire FS by mount options right now. ioctls are needed to set this on a per file or per directory basis. This has been proposed previously, but VFS developers wanted us to use generic ioctls rather than btrfs-specific ones. According to c

[PATCH 1/2 v2] Btrfs: add datacow flag in inode flag

2011-03-21 Thread liubo
For datacow control, the corresponding inode flags are needed. This is for btrfs use. v1->v2: Change FS_COW_FL to another bit due to conflict with the upstream e2fsprogs Signed-off-by: Liu Bo --- include/linux/fs.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/inclu

Re: [PATCH 1/2] Btrfs: add datacow flag in inode flag

2011-03-16 Thread liubo
gt; so there is a conflict with FS_COW_FL and EXT4_SNAPFILE_FL. I don't know >>> the semantics of those two flags enough to say for sure whether it is >>> reasonable that they alias to each other, but at first glance "COW" and >>> "SNAPSHOT" don'

Re: [PATCH 1/2] Btrfs: fix OOPS of empty filesystem after balance

2011-03-10 Thread liubo
On 03/07/2011 10:13 AM, liubo wrote: > btrfs will remove unused block groups after balance. > When a empty filesystem is balanced, the block group with tag "DATA" may be > dropped, and after umount and mount again, it will not find "DATA" space_info > and l

[PATCH 2/2] Btrfs: fix memory leak of empty filesystem after balance

2011-03-06 Thread liubo
After Josef's patch(commit 3c14874acc71180553fb5aba528e3cf57c5b958b), btrfs will exclude super bytes when reading block groups(by marking a extent state UPTODATE). However, these bytes do not get freed while balance remove unused block groups, and we won't process those removed ones any more, whe

[PATCH 1/2] Btrfs: fix OOPS of empty filesystem after balance

2011-03-06 Thread liubo
btrfs will remove unused block groups after balance. When a empty filesystem is balanced, the block group with tag "DATA" may be dropped, and after umount and mount again, it will not find "DATA" space_info and lead to OOPS. So we initial the necessary space_infos(DATA, SYSTEM, METADATA) to avoid

[PATCH 2/2] Btrfs: Per file/directory controls for COW and compression

2011-03-03 Thread liubo
Data compression and data cow are controlled across the entire FS by mount options right now. ioctls are needed to set this on a per file or per directory basis. This has been proposed previously, but VFS developers wanted us to use generic ioctls rather than btrfs-specific ones. According to c

[PATCH 1/2] Btrfs: add datacow flag in inode flag

2011-03-03 Thread liubo
For datacow control, the corresponding inode flags are needed. This is for the following patch. Signed-off-by: Liu Bo --- include/linux/fs.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/linux/fs.h b/include/linux/fs.h index 63d069b..bef47ff 100644 --- a/incl

Re: [RFC PATCH] Btrfs: add ioctl to set compress or cow per file/dir

2011-02-24 Thread liubo
On 02/25/2011 02:39 AM, Chris Mason wrote: > Excerpts from Andreas Dilger's message of 2011-02-24 13:37:52 -0500: >> On 2011-02-24, at 2:40 AM, liubo wrote: >>> #define FS_DIRECTIO_FL0x0010 /* Use direct i/o */ >>> +#define FS_NOCOW_FL

Re: [RFC PATCH] Btrfs: add ioctl to set compress or cow per file/dir

2011-02-24 Thread liubo
we are dealing with is directory, should this behaviour be >> recursive or not? >> I'm inclined to leave these recursive things to btrfs-progs if this is >> necessary. > > I'd say that if we rename a file into a directory it does inherit, but > not make it recursive. > ok, got it. I will send a new version based on this thread. Thanks a lot for reviewing! thanks, liubo > -chris > -- 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: [2.6.38-rc6] create->rebalance->mount crash...

2011-02-24 Thread liubo
On 02/24/2011 04:13 PM, Daniel J Blueman wrote: > When creating a filesystem (single or redundant) with BTRFS and > subsequently executing a balance [1], we see a kernel oops at the next > mount [2]. > Hi, Daniel, After digging this, I've come up with a patch on this, would you please test it on

[RFC PATCH] Btrfs: add ioctl to set compress or cow per file/dir

2011-02-24 Thread liubo
Data compression and data cow are controlled across the entire FS by mount options right now. ioctls are needed to set this on a per file or per directory basis. This has been proposed previously, but VFS developers wanted us to use generic ioctls rather than btrfs-specific ones. We need to fit

[PATCH] Btrfs: fix return value of setflags ioctl

2011-02-24 Thread liubo
setflags ioctl should return error when any checks fail. Signed-off-by: Liu Bo --- fs/btrfs/ioctl.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 02d224e..e397da4 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -213

[PATCH v3] btrfs: make inode ref log recovery faster

2011-02-23 Thread liubo
When we recover from crash via write-ahead log tree and process the inode refs, for each btrfs_inode_ref item, we will 1) check if we already have a perfect match in fs/file tree, if we have, then we're done. 2) search the corresponding back reference in fs/file tree, and check all the names

[PATCH v2] btrfs: make inode ref log recovery faster

2011-02-22 Thread liubo
When we recover from crash via write-ahead log tree and process the inode refs, for each btrfs_inode_ref item, we will 1) check if we already have a perfect match in fs/file tree, if we have, then we're done. 2) search the corresponding back reference in fs/file tree, and check all the names

Re: [PATCH] btrfs: make inode ref log recovery faster

2011-02-22 Thread liubo
On 02/23/2011 09:30 AM, Josef Bacik wrote: > On Wed, Feb 23, 2011 at 09:12:36AM +0800, liubo wrote: >> On 02/22/2011 10:32 PM, David Sterba wrote: >>> Hi, >>> >>> no deeper analysis done, but the double free error was obvious :) >>> >>>

Re: [PATCH] btrfs: make inode ref log recovery faster

2011-02-22 Thread liubo
On 02/22/2011 10:32 PM, David Sterba wrote: > Hi, > > no deeper analysis done, but the double free error was obvious :) > > On Tue, Feb 22, 2011 at 07:42:25PM +0800, liubo wrote: >> When we recover from crash via write-ahead log tree and process >> the inode refs, fo

[PATCH] btrfs: make inode ref log recovery faster

2011-02-22 Thread liubo
When we recover from crash via write-ahead log tree and process the inode refs, for each btrfs_inode_ref item, we will 1) check if we already have a perfect match in fs/file tree, if we have, then we're done. 2) search the corresponding back reference in fs/file tree, and check all the names

Re: Building btrfs as a dkms module on Debian

2011-02-15 Thread liubo
d9b09a177a481eda256447c881f014f29034fe: include/linux/blkdev.h: #define BLKDEV_IFL_WAIT (1 << BLKDEV_WAIT) #define BLKDEV_IFL_BARRIER (1 << BLKDEV_BARRIER) #define BLKDEV_IFL_SECURE (1 << BLKDEV_SECURE) Maybe this is helpful.:) thanks, liubo > > Thanks >

[PATCH 3/3] btrfs: fix missing break in switch phrase

2011-01-25 Thread liubo
There is a missing break in switch, fix it. Signed-off-by: Liu Bo --- fs/btrfs/print-tree.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/fs/btrfs/print-tree.c b/fs/btrfs/print-tree.c index 0d126be..fb2605d 100644 --- a/fs/btrfs/print-tree.c +++ b/fs/btrfs/print-tree.

[PATCH 1/3] btrfs: fix uncheck memory allocation in btrfs_submit_compressed_read

2011-01-25 Thread liubo
btrfs_submit_compressed_read() is lack of memory allocation checks and corresponding error route. After this fix, if it comes to "no memory" case, errno will be returned to userland step by step, and tell users this operation cannot go on. Signed-off-by: Liu Bo --- fs/btrfs/compression.c | 2

[PATCH 2/3] btrfs: fix several uncheck memory allocations

2011-01-25 Thread liubo
To make btrfs more stable, add several missing necessary memory allocation checks, and when no memory, return proper errno. We've checked that some of those -ENOMEM errors will be returned to userspace, and some will be catched by BUG_ON() in the upper callers, and none will be ignored silently.

Re: [PATCH] btrfs: fix return value check of btrfs_start_transaction()

2011-01-20 Thread liubo
On 01/21/2011 12:09 AM, Josef Bacik wrote: > On Thu, Jan 20, 2011 at 03:19:37PM +0900, Tsutomu Itoh wrote: >> The error check of btrfs_start_transaction() is added, and the mistake >> of the error check on several places is corrected. >> > > I'd rather we go through and have these things return a

Re: [PATCH] Btrfs: forced readonly mounts on errors

2011-01-17 Thread liubo
l we have a fully consistent set > of fields in the super block. The super_copy is changed as the > transaction progresses. > > So, this memcpy isn't quite safe. We should simply set the flag on the > super_for_commit and the super_copy individually. > Got it, thanks for pointing

[PATCH] Btrfs: forced readonly mounts on errors

2011-01-06 Thread liubo
This patch comes from "Forced readonly mounts on errors" ideas. As we know, this is the first step in being more fault tolerant of disk corruptions instead of just using BUG() statements. The major content: - add a framework for generating errors that should result in filesystems going readonl

Re: [RFC PATCH 2/5 v3] Btrfs: avoid transaction stuff when btrfs is readonly

2010-12-15 Thread liubo
On 12/16/2010 12:03 AM, Chris Mason wrote: > Excerpts from liubo's message of 2010-12-15 04:12:14 -0500: >> On 12/15/2010 04:45 PM, Yan, Zheng wrote: >>> On Fri, Dec 3, 2010 at 4:16 PM, liubo wrote: >>>> When the filesystem is readonly, avoid transaction stuff

Re: [RFC PATCH 2/5 v3] Btrfs: avoid transaction stuff when btrfs is readonly

2010-12-15 Thread liubo
On 12/15/2010 04:45 PM, Yan, Zheng wrote: > On Fri, Dec 3, 2010 at 4:16 PM, liubo wrote: >> When the filesystem is readonly, avoid transaction stuff by checking >> MS_RDONLY >> at start transaction time. >> >> Signed-off-by: Liu Bo >> --- >>

Re: [RFC PATCH 0/5 v3] Btrfs: Add readonly support to replace BUG_ON phrase

2010-12-15 Thread liubo
Hi, chris, Is there any comment on this "Forced readonly mounts on errors" patchset? thanks, Liu Bo On 12/03/2010 04:15 PM, liubo wrote: > Btrfs has a number of BUG_ON()s, which may lead btrfs to unpleasant panic. > Meanwhile, they are very ugly and should be handled

  1   2   >