Hi all,
I have a question about replacing a drive in raid10 (and linux kernel 3.8.4).
A bad disk was physical removed from the server. After this a new disk
was added with btrfs device add /dev/sdg /btrfs to the raid10 btrfs
FS.
After this the server was rebooted and I mounted the filesystem in
We reserve the space for csums only when we write data into a file, in
the other cases, such as tree log, log replay, we don't do reservation,
so we can use the reservation of the transaction handle just for the former.
And for the latter, we should use the tree's own reservation. But the
function
On Thu, Mar 28, 2013 at 1:54 AM, Joeri Vanthienen
m...@joerivanthienen.be wrote:
Hi all,
I have a question about replacing a drive in raid10 (and linux kernel 3.8.4).
A bad disk was physical removed from the server. After this a new disk
was added with btrfs device add /dev/sdg /btrfs to the
It is very likely that there are several blocks in bio, it is very
inefficient if we get their csums one by one. This patch improves
this problem by getting the csums in batch.
According to the result of the following test, the execute time of
__btrfs_lookup_bio_sums() is down by ~28%(300us -
bytenr in btrfs_sector_sum is unnecessary, because the extents that
btrfs_sector_sum points to are continuous，we can find out the expected
checksums by btrfs_ordered_sum's bytenr and the offset, so we can
remove btrfs_sector_sum's bytenr.
After removing bytenr, we don't use the while loop to get
If we don't find the expected csum item, but find a csum item which is
adjacent to the specified extent, we should return -EFBIG, or we should
return -ENOENT. But btrfs_lookup_csum() return -EFBIG even the csum item
is not adjacent to the specified extent. Fix it.
Signed-off-by: Miao Xie
set_extent_bit()'s (u64 *failed_start) expects NULL not 0.
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/extent_io.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index f173c5a..f22243f 100644
---
bytenr in btrfs_sector_sum is unnecessary, because the extents that
btrfs_sector_sum points to are continuous, we can find out the expected
checksums by btrfs_ordered_sum's bytenr and the offset, so we can
remove btrfs_sector_sum's bytenr.
After removing bytenr, we don't use the while loop to get
From: Wang Shilong wangsl-f...@cn.fujitsu.com
This patch introduces mutex lock 'quota_lock', and makes
all the user change for quota protected by quota_lock.
Signed-off-by: Wang Shilong wangsl-f...@cn.fujitsu.com
Reviewed-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/ctree.h |3 +++
The original code has only one spin_lock 'qgroup_lock' to protect quota
configurations on memory. If we want to add a BTRFS_QGROUP_INFO_KEY,
it will be added to Btree firstly and then update quota configurations
on memory, however,a race condition may happen between these operations.
For example:
From: Wang Shilong wangsl-f...@cn.fujitsu.com
We use mutex_lock to protect all the user change operaions.
So when we are calling find_qgroup_rb() to check whether
qgroup exists, we don't have to hold spin_lock.
Besides, when enabling/disabling quota,it must be single
thread when operations come
From: Wang Shilong wangsl-f...@cn.fujitsu.com
For creating a qgroup, if the qgroup exsits, return -EEXIST.
For destroying a qgroup, if there are qgroup relations, return -EBUSY,
if the qgroup dosen't exist, return -ENOENT.
Signed-off-by: Wang Shilong wangsl-f...@cn.fujitsu.com
Reviewed-by: Miao
From: Wang Shilong wangsl-f...@cn.fujitsu.com
If the specified qgroup relation dosen't exist, removing qgroup operations
will return -ENOENT;
If the specified qgroup relation exists, assigning qgroup relations will
return -EEXIST.
Signed-off-by: Wang Shilong wangsl-f...@cn.fujitsu.com
From: Wang Shilong wangsl-f...@cn.fujitsu.com
We should check whether a qgroup exists before updating qgroup limit,
if the relative qgroup dosen't exsit, return -EEXIST and do not join
a transaction, fix it.
Signed-off-by: Wang Shilong wangsl-f...@cn.fujitsu.com
Reviewed-by: Miao Xie
From: Wang Shilong wangsl-f...@cn.fujitsu.com
The original code forgot to check 'inherit',we should gurantee
that all the qgroups in the struct 'inherit' exist before
btrfs_qgroup_inherit().
Signed-off-by: Wang Shilong wangsl-f...@cn.fujitsu.com
Reviewed-by: Miao Xie mi...@cn.fujitsu.com
---
From: Wang Shilong wangsl-f...@cn.fujitsu.com
Steps to reproduce:
mkfs.btrfs disk
mount disk mnt
btrfs quota enable mnt
btrfs sub create mnt/subv
i=1
while [ $i -le 1 ]
do
dd if=/dev/zero of=mnt/subv/data_$i bs=1K
(Resending without the attachment which didn't seem to make it thru...)
Hi folks,
This time, at reboot, one of my machines won't come up.
Starting it in single and verbose mode shows that BTRFS looks dead (or
at least seriously wounded) :
Kernel seems to mount BTRFS, then swap, then sits there
On Thu, Mar 28, 2013 at 05:51:18AM -0600, Swâmi Petaramesh wrote:
(Resending without the attachment which didn't seem to make it thru...)
Hi folks,
This time, at reboot, one of my machines won't come up.
Starting it in single and verbose mode shows that BTRFS looks dead (or
at least
On Thu, Mar 28, 2013 at 04:54:46AM -0600, Wang Shilong wrote:
From: Wang Shilong wangsl-f...@cn.fujitsu.com
If the specified qgroup relation dosen't exist, removing qgroup operations
will return -ENOENT;
If the specified qgroup relation exists, assigning qgroup relations will
return
Quoting Miao Xie (2013-03-28 05:03:52)
bytenr in btrfs_sector_sum is unnecessary, because the extents that
btrfs_sector_sum points to are continuous, we can find out the expected
checksums by btrfs_ordered_sum's bytenr and the offset, so we can
remove btrfs_sector_sum's bytenr.
I really like
From: Wang Shilong wangsl-f...@cn.fujitsu.com
If the specified qgroup relation dosen't exist, removing qgroup operations
will return -ENOENT;
If the specified qgroup relation exists, assigning qgroup relations will
return -EEXIST.
Signed-off-by: Wang Shilong wangsl-f...@cn.fujitsu.com
Hello,
On Thu, Mar 28, 2013 at 04:54:46AM -0600, Wang Shilong wrote:
From: Wang Shilong wangsl-f...@cn.fujitsu.com
If the specified qgroup relation dosen't exist, removing qgroup operations
will return -ENOENT;
If the specified qgroup relation exists, assigning qgroup relations will
On Tue, Mar 19, 2013 at 08:16:41PM +0800, Liu Bo wrote:
On Mon, Mar 18, 2013 at 03:16:12PM +0100, David Sterba wrote:
I've noticed that return value from merge_reloc_roots is never checked
in the callers. Did you verify that this is ok?
Yeah, it's fine.
Then it's ok to change return value
When working with a user with a broken file system I noticed I wasn't able to
read some of the blocks properly from the restored image. This is because his
extent tree was corrupt and was missing references to some of the blocks, which
means they weren't copied into the image when he generated
I made open_ctree fail if the chunk tree couldn't be open, which means that fsck
now segfaults if it can't open the chunk tree. So fix fsck to check the fs_info
we get back from open_ctree_fsinfo to make sure it's valid and exit if it's not
instead of segfaulting. Thanks,
Signed-off-by: Josef
On Thu, Mar 28, 2013 at 04:10:41PM +0800, Miao Xie wrote:
It is very likely that there are several blocks in bio, it is very
inefficient if we get their csums one by one. This patch improves
this problem by getting the csums in batch.
According to the result of the following test, the
On Thu, Mar 28, 2013 at 04:11:38PM +0800, Miao Xie wrote:
bytenr in btrfs_sector_sum is unnecessary, because the extents that
btrfs_sector_sum points to are continuous，we can find out the expected
checksums by btrfs_ordered_sum's bytenr and the offset, so we can
remove btrfs_sector_sum's
On Thu, Mar 28, 2013 at 10:38:34PM +0800, Liu Bo wrote:
On Thu, Mar 28, 2013 at 04:11:38PM +0800, Miao Xie wrote:
bytenr in btrfs_sector_sum is unnecessary, because the extents that
btrfs_sector_sum points to are continuous，we can find out the expected
checksums by btrfs_ordered_sum's
Le 28/03/2013 14:19, Josef Bacik a écrit :
Can you capture the output and post it somewhere so I can see it? Thanks,
Hi Josef,
I just uploaded the screenshot here: http://dl.free.fr/pRabNdCsf (You
will need to type in your email address or the list's one to retrieve it)
Meanwhile I did some
Looking at a recent user problem I noticed there are weird cases we could
possibly be leaving csums in place for an extent we've free'd. I don't think
this can happen unless the extent tree is also corrupt, but just in case I'm
adding sanity checks to btrfsck. This way we will catch this if it
On Thu, Mar 28, 2013 at 09:55:26AM -0600, Swâmi Petaramesh wrote:
Le 28/03/2013 14:19, Josef Bacik a écrit :
Can you capture the output and post it somewhere so I can see it? Thanks,
Hi Josef,
I just uploaded the screenshot here: http://dl.free.fr/pRabNdCsf (You
will need to type in your
On Thu, Mar 28, 2013 at 09:55:26AM -0600, Swâmi Petaramesh wrote:
Le 28/03/2013 14:19, Josef Bacik a écrit :
Can you capture the output and post it somewhere so I can see it? Thanks,
Hi Josef,
I just uploaded the screenshot here: http://dl.free.fr/pRabNdCsf (You
will need to type in your
A user reported a hang on mount and it looks like we are waiting for the inode
cache to fill up. The caching thread will stop if it sees that we are
committing a transaction every time it has to move leaves and then it will
re-search. But we call btrfs_find_free_ino() inside of a transaction so
Le 28/03/2013 19:05, Josef Bacik a écrit :
Actually I see the deadlock now, sorry, I'll fix it up and send a patch.
Meanwhile, I booted in PartedMagic again (My Hero !), mounted the FS,
chrooted into it, mounted everything under it, then I rebuilt the
initramfs, unmounted and restarted the usual
On Thu, 28 Mar 2013 22:41:50 +0800, Liu Bo wrote:
On Thu, Mar 28, 2013 at 10:38:34PM +0800, Liu Bo wrote:
On Thu, Mar 28, 2013 at 04:11:38PM +0800, Miao Xie wrote:
bytenr in btrfs_sector_sum is unnecessary, because the extents that
btrfs_sector_sum points to are continuous，we can find out the
On Thu, Mar 28, 2013 at 02:26:06PM -0400, Josef Bacik wrote:
A user reported a hang on mount and it looks like we are waiting for the inode
cache to fill up. The caching thread will stop if it sees that we are
committing a transaction every time it has to move leaves and then it will
Creating a btrfs file system using
btrfs-progs-0.20.rc1.20130308git704a08c-1.fc19, and either kernel 3.6.10-4.fc18
or 3.9.0-0.rc3.git0.3.fc19, makes a file system that cannot be mounted by
kernel 3.6.10-4.fc18. It can be mounted by kernel 3.8.4. I haven't tested any
other 3.8, or any 3.7
37 matches
Mail list logo
