Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
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 from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord
this one. I'm sorry.
thanks,
liubo
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
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 80d6148..9b495ce 100644
--- a/fs/btrfs/extent-tree.c
deletions(-)
This fixes the oops for me. The bug was a regression in 2.6.39, I believe.
Tested-by: Andy Lutomirski l...@mit.edu
Thanks a lot for testing!
thanks,
liubo
--Andy
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord
5089b598ce74fcfc ]---
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 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 search on the io_tree, and if we
] system_call_fastpath+0x16/0x1b
---[ end trace 9a65800674b03b84 ]---
thanks,
liubo
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/ctree.c | 10 +-
fs/btrfs/ctree.h |5 ++---
fs/btrfs/disk-io.c |3 ++-
fs/btrfs/extent-tree.c | 20 +++-
fs/btrfs
, 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
thanks,
liubo
in my sysbench write + fsync test:
451.01Kb/sec - 4.3621Mb/sec
Also, I've run
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 is
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
Josef
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
;
direct assignment, no btrfs_ino as in the first hunk
This is a special case, where is new_inode-i_ino is
BTRFS_EMPTY_SUBVOL_DIR_OBJECTID,
while BTRFS_I(new_inode)-location.objectid is 256.
Thanks for the reviewing!
liubo
thanks,
ret = btrfs_unlink_subvol(trans, dest
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 unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
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 liubo2...@cn.fujitsu.com
---
fs/btrfs/extent-tree.c |2 +-
1 files
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:
Hi,
I encountered following panic using 'btrfs-unstable + for-linus'
kernel
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 maybe I miss something to reproduce it?
thanks,
liubo
Thanks,
Tsutomu
)
return -ENOMEM;
thanks,
liubo
---
Tsutomu
6device fsid 25424ba6b248ec38-64dc2480b05ec68c devid 5 transid 4 /dev/sdc8
6device fsid 25424ba6b248ec38-64dc2480b05ec68c devid 1 transid 7 /dev/sdc3
6btrfs: enabling disk space
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
#
# btrfs fi sh /dev/sdc3
Label: none uuid: 38ec48b2-a64b-4225
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.
/test5 is as follows:
# mount -o space_cache,compress=lzo /dev/sdc3 /test5
#
# btrfs fi sh /dev
.
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
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,
and I found that the bottleneck
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.
Jan Schmidt has a patch for scrub nearly ready, that does some
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 code assumes the inode isn't in the log and hits
-EEXIST if it finds
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 in the btree blocks.
There are a few solutions to this, we
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, Steven,
I've seen your latest git-pull, but these 2
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
mentioned in the
thread.
thanks,
liubo
Josef
--
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 this, we can use some of the reserved
fields in the super for the generation numbers of the roots the super
points to, and use whichever one is bigger when we read things in.
All right, I'm going to dig it more.
Liubo, since we'll leave this one for .41, I'll take your smaller patch
that just
;
+ atomic_t reada_in_flight;
+ u64 reada_next;
+ struct reada_zone *reada_curr_zone;
struct reada_zone has not been defined yet...
thanks,
liubo
+ struct radix_tree_root reada_zones;
+ struct radix_tree_root reada_extents;
};
struct btrfs_fs_devices {
--
To unsubscribe from
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 Chris
.
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
eb;
- }
num_copies = btrfs_num_copies(root-fs_info-mapping_tree,
eb-start, eb-len);
if (num_copies == 1) {
thanks,
liubo.
Unfortunately, now btrfs will NOT mount the drive, so I am now
completely
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 the
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
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-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
include
code, since it will have to deal with finding extents in the log tree
and merging in the new extents from the file.
I've been thinking of this extent buffer with sub transid stuff for a while,
and will give it a try. :)
thanks,
liubo.
-chris
--
To unsubscribe from this list: send the line
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 dste...@suse.cz
---
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 100644
into tree log during fsync(). Btrfs now uses a brute force approach to
ensure to get the most uptodate copies of everything, and this results in a bad
performance. To change the brute way is bugging me a lot...
thanks,
liubo
Josef
--
To unsubscribe from this list: send the line unsubscribe linux
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
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 +++---
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 liubo2...@cn.fujitsu.com
---
lib/e2p/pf.c |1 +
lib/ext2fs/ext2_fs.h |1 +
On 04/18/2011 04:41 PM, Coly Li wrote:
On 2011年04月18日 15:37, liubo Wrote:
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
debugfs/htree.c|2 +-
e2fsck/pass1.c | 22 +++---
e2fsck/pass2.c |2 +-
e2fsck/pass4.c |2 +-
e2fsck
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 32bit box.
Signed-off-by: Liu Bo liubo2
To avoid 64-32 truncating WARNING, update btrfs's tracepoints.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
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
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 liubo2...@cn.fujitsu.com
---
include/linux/ftrace_event.h | 12
this thing will go away
first.
Thanks a lot for testing, 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
==
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 what we want, or a spare one?
thanks,
liubo
Signed-off-by: Josef
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
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 liubo2...@cn.fujitsu.com
---
include/linux/ftrace_event.h | 12
include/trace/events/btrfs.h
-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 by
mount
options right now. ioctls are needed to set
On 04/02/2011 06:41 PM, Sergei Trofimovich wrote:
On Sat, 02 Apr 2011 17:37:58 +0800
liubo liubo2...@cn.fujitsu.com wrote:
On 04/02/2011 05:19 PM, Sergei Trofimovich wrote:
The partition is a physical ~5GB --mixed lzo compressed partition.
The kernel 2.6.39-rc1 + reverted commit
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 those
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](), only have unsigned long, so on 32bit box
From: Miao Xie mi...@cn.fujitsu.com
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
to neglect the version, I found this warning while compiling
the latest for-linus tree (top commit:
c1e1f82c56af1a286fd747e809c94628c2ca15fb).
thanks,
liubo
-chris
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/volumes.c | 23 +++
1 files changed, 15
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.
When a empty filesystem is balanced, the block group
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 into why btrfs hits bugs and be greatly
helpful
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 liubo2...@cn.fujitsu.com
[PATCH] Btrfs: fix compile warnings of btrfs tracepoint on 32bit box
include/trace/events/btrfs.h:47:1: warning
type
include/trace/events/btrfs.h:68:1: warning: large integer implicitly
truncated to unsigned type
include/trace/events/btrfs.h:144:1: warning: large integer implicitly
truncated to unsigned type
Ahh, I figure it out.
Will send a new version to clear warnings.
Thanks,
liubo
-chris
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]
From: Liu Bo liubo2...@cn.fujitsu.com
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
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 liubo2...@cn.fujitsu.com
---
include/linux/fs.h |2 ++
1 files changed, 2 insertions(+), 0
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
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(location, BTRFS_INODE_ITEM_KEY
.
Fine with that, but it's up to Chris. :)
thanks,
liubo
EXT4_SNAPFILE_DELETED_FL is a persistent state of a snapshot file,
which is no longer
available as a mountable device, but cannot be unlinked because it
holds changed data sets
needed by older snapshots.
EXT4_SNAPFILE_SHRUNK_FL
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 lead to OOPS.
So we initial the necessary
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
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,
For datacow control, the corresponding inode flags are needed.
This is for the following patch.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
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
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
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
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_FL0x0020 /* Do not cow file */
+#define
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, for each btrfs_inode_ref item, we
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 Tue, Feb 22, 2011 at 07:42:25PM +0800, liubo wrote:
When we recover from
BLKDEV_BARRIER)
#define BLKDEV_IFL_SECURE (1 BLKDEV_SECURE)
Maybe this is helpful.:)
thanks,
liubo
Thanks
--
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
There is a missing break in switch, fix it.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
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
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 an error
build from here.
Great!
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
--
To unsubscribe from this list: send the line
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
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 more propriately
On 12/15/2010 04:45 PM, Yan, Zheng wrote:
On Fri, Dec 3, 2010 at 4:16 PM, liubo liubo2...@cn.fujitsu.com wrote:
When the filesystem is readonly, avoid transaction stuff by checking
MS_RDONLY
at start transaction time.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs
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 liubo2...@cn.fujitsu.com wrote:
When the filesystem is readonly, avoid transaction stuff by checking
While compiling btrfs, I got belows:
CC [M] fs/btrfs/inode.o
fs/btrfs/inode.c: In function ‘btrfs_end_dio_bio’:
fs/btrfs/inode.c:5720: warning: format ‘%lu’ expects type ‘long unsigned int’,
but argument 4 has type ‘sector_t’
LD [M] fs/btrfs/btrfs.o
Building modules, stage 2.
MODPOST 1
On 12/08/2010 06:01 PM, liubo wrote:
While compiling btrfs, I got belows:
CC [M] fs/btrfs/inode.o
fs/btrfs/inode.c: In function ‘btrfs_end_dio_bio’:
fs/btrfs/inode.c:5720: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 4 has type ‘sector_t’
LD [M] fs/btrfs
On 12/07/2010 04:48 AM, Josef Bacik wrote:
Currently BTRFS has a problem where any subvol's will have the same inode
numbers as other files in the parent subvol. This can cause problems with
userspace apps that depend on inode numbers being unique across a volume. So
in
order to solve this
Btrfs has a number of BUG_ON()s, which may lead btrfs to unpleasant panic.
Meanwhile, they are very ugly and should be handled more propriately.
There are mainly two ways to deal with these BUG_ON()s.
1. For those errors which can be handled well by callers, we just return their
error number to
This patch provide a new error handle interface for those errors that handled
by current BUG_ONs.
In order to protect btrfs from panic, when it comes to those BUG_ON errors,
the interface forces btrfs readonly and saves the FS state to disk. And the
filesystem can be umounted, although mabye
When the filesystem is readonly, avoid transaction stuff by checking MS_RDONLY
at start transaction time.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/transaction.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/transaction.c
Add filesystem state and a flags to tell if the filesystem is
valid or insane now.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/ctree.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 8db9234..92b5ca2
Since there is a filesystem state, we should deal with it carefully at mount,
umount and remount.
- At mount, the FS state should be checked if there is error on these FS.
If it does have, btrfsck is recommended.
- At umount, the FS state should be saved into disk for consistency.
v2-v3:
do
btrfs may do log replay even as mounted readonly, since we have added
readonly check at start transaction time, in order to keep the original
attribute, it needs to set and to restore readonly flags around log
replay.
However, we do not permit log replay when btrfs is insane, and log replay
can
Btrfs has a number of BUG_ON()s, which may lead btrfs to unpleasant panic.
Meanwhile, they are very ugly and should be handled more propriately.
There are mainly two ways to deal with these BUG_ON()s.
1. For those errors which can be handled well by callers, we just return their
error number to
Add filesystem state and a flags to tell if the filesystem is
valid or insane now.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/ctree.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 8db9234..92b5ca2
When the filesystem is readonly, avoid transaction stuff by checking MS_RDONLY
at
start transaction time.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/transaction.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/transaction.c
This patch provide a new error handle interface for those errors that handled
by current BUG_ONs.
In order to protect btrfs from panic, when it comes to those BUG_ON errors,
the interface forces btrfs readonly and saves the FS state to disk. And the
filesystem can be umounted, although mabye
Since there is a filesystem state, we should deal with it carefully at mount,
umount and remount.
- At mount, the FS state should be checked if there is error on these FS.
If it does have, btrfsck is recommended.
- At umount, the FS state should be saved into disk for consistency.
On 12/02/2010 10:29 AM, Tsutomu Itoh wrote:
Hi,
I found 1 typo.
(2010/12/01 19:21), liubo wrote:
Since there is a filesystem state, we should deal with it carefully at mount,
umount and remount.
- At mount, the FS state should be checked if there is error on these FS.
If it does
On 12/01/2010 06:20 PM, liubo wrote:
When the filesystem is readonly, avoid transaction stuff by checking
MS_RDONLY at
start transaction time.
This patch may lead btrfs panic.
Since btrfs allows transaction under readonly fs state, which is a bit weird,
btrfs
does not even check
On 12/02/2010 12:28 PM, Yan, Zheng wrote:
On Thu, Dec 2, 2010 at 11:42 AM, liubo liubo2...@cn.fujitsu.com wrote:
On 12/01/2010 06:20 PM, liubo wrote:
When the filesystem is readonly, avoid transaction stuff by checking
MS_RDONLY at
start transaction time.
This patch may lead btrfs panic
On 12/02/2010 01:41 PM, Mike Fedyk wrote:
On Wed, Dec 1, 2010 at 8:28 PM, Yan, Zheng yanzh...@21cn.com wrote:
On Thu, Dec 2, 2010 at 11:42 AM, liubo liubo2...@cn.fujitsu.com wrote:
On 12/01/2010 06:20 PM, liubo wrote:
When the filesystem is readonly, avoid transaction stuff by checking
On 11/30/2010 04:10 AM, Josef Bacik wrote:
On Thu, Nov 25, 2010 at 05:52:47PM +0800, Miao Xie 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 more propriately.
There are mainly two ways to deal with these
On 11/30/2010 10:30 AM, Josef Bacik wrote:
On Tue, Nov 30, 2010 at 10:03:58AM +0800, liubo wrote:
On 11/30/2010 04:10 AM, Josef Bacik wrote:
On Thu, Nov 25, 2010 at 05:52:47PM +0800, Miao Xie wrote:
Btrfs has a number of BUG_ON()s, which may lead btrfs to unpleasant panic.
Meanwhile
1 - 100 of 114 matches
Mail list logo
