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
; [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
->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
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
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
_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
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
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
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
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&
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
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 ++-
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
> 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
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
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
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
>&
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
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
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:
>>>>
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
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
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
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
>>
t_key.objectid < BTRFS_FIRST_FREE_OBJECTID)
+ return 0;
+
path = btrfs_alloc_path();
if (!path)
return -ENOMEM;
thanks,
liubo
> ---
> Tsutomu
>
>
>
> <6>device fsid
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
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,
>
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.
>&
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>>
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.
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 +
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 ++
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
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,
:
> 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
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
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
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
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
> 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
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
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.
>
>
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](),
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
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
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
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
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
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
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
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
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
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,
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(
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
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
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'
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
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
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
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
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
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
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
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
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
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
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
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
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 :)
>>>
>>>
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
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
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
>
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.
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
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.
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
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
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
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
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
>> ---
>>
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 - 100 of 140 matches
Mail list logo
