NOTE:
This patchset is based on danger branch.
We've been sufferring two big bugs with sub transid:
one is a bug related to root's last_snapshot, the other is a bug related to
disk extent refs' generation.
1) The first patch fixes a warning,
2) the second one fixes the last_snapshot bug,
3) the
We've forgotten to update root's last_snapshot gen to the latest sub transid,
so that we will free some extent buffers unexpectedly. And this will cause
a inconsistent tree crash.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/transaction.c |3 ++-
1 files changed, 2
Should check for sub transid instead.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/ctree.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index fa34b74..4a96337 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@
We've suffered some transid mismatches by using sub transid,
here is a case:
before:
parent A (gen = x) parent B(gen = x)
\/
\ /
\/
block C (gen = x)
After We can update block C via
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/ctree.c | 17 -
fs/btrfs/ctree.h |2 ++
fs/btrfs/transaction.c |8
3 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 4a96337..2b38acd
We used to set disk extent refs' generation with transid,
but now with sub transid, it will cause a generation mismatch between
a tree block and its corresponding disk extent ref, and this will lead
to balance and scrub's crash.
Since these disk extent refs are delayed and stored in a rbtree,
the
On 7/10/2011 4:21 AM, Arne Jansen wrote:
btrfs qgroup limit [--exclusive] size|none qgroupid path
This sets actual limits on a qgroup. If --exclusive is given, the
exclusive usage is limited instead of the referenced. I don't know
if there are use cases where both values need a (possibly
1) As of right now, btrfs's fsck is done when it's done. So don't hold your
breath, I'm afraid.
2) What errors do you get on mount? It may be as simple as changing your fstab
entry such that fsck isn't attempted to be run. (Change the last column to
0.)
-Ken
On Sat, 19 Nov 2011 14:01:41
From: Justin P. Mattock justinmatt...@gmail.com
The patch below removes an extra semicolon.
Note: I have not compile tested this patch, so am unsure if this breaks things.
Signed-off-by: Justin P. Mattock justinmatt...@gmail.com
CC: Chris Mason chris.ma...@oracle.com
CC:
On 11/21/2011 12:20 PM, Arne Jansen wrote:
On 11/21/2011 05:06 PM, Phillip Susi wrote:
On 7/10/2011 4:21 AM, Arne Jansen wrote:
btrfs qgroup limit [--exclusive]size|noneqgroupid path
btrfs qgroup limit 10g /usr
That should be simple enough for the common use case.
Wouldn't that make the
Al pointed out we have some random problems with the way we account for
num_workers_starting in the async thread stuff. First of all we need to make
sure to decrement num_workers_starting if we fail to start the worker, so make
__btrfs_start_workers do this. Also fix __btrfs_start_workers so
[I accidentally failed to include the list in the previous reply]
On 11/21/2011 07:51 PM, Arne Jansen wrote:
On 11/21/2011 07:29 PM, Phillip Susi wrote:
On 11/21/2011 12:20 PM, Arne Jansen wrote:
On 11/21/2011 05:06 PM, Phillip Susi wrote:
On 7/10/2011 4:21 AM, Arne Jansen wrote:
I also have
On Fri, Nov 18, 2011 at 2:17 PM, Gregory Farnum
gregory.far...@dreamhost.com wrote:
I'm running Ceph OSDs on btrfs and have managed to corrupt several of
them so that on mount I get an error:
root@cephstore6356:~# mount /dev/sde1 /mnt/osd.2/
2011 Nov 18 10:44:52 cephstore6356 [68494.771472]
Thank you for answering.
2) I get this error when mounting:
couldn't open because of unsupported option features (8).
fsck.btrfs: disk-io.c:679: open_ctree_fd: Assertion `!(1)' failed.
My current mount options are
defaults,compress=lzo,subvol=@home
I have tried removing the compress=lzo with no
If I change the last column to 0 (aka ignore the warning), my file
system will silently corrupt - is this true?
On 21 November 2011 17:27, Ken D'Ambrosio k...@jots.org wrote:
1) As of right now, btrfs's fsck is done when it's done. So don't hold your
breath, I'm afraid.
2) What errors do you
On Mon, Nov 21, 2011 at 2:25 PM, Gregory Farnum
gregory.far...@dreamhost.com wrote:
So if I don't hear anything else or see this again I guess I'll just
hope that the cause of this corruption is now eliminated, since it's
at least handled better in the current code.
Thanks!
-Greg
Well, that
Hi everyone,
The for-linus branch of the linux-btrfs repo has some important fixes:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
The most important in the bunch fixes the btrfs cache flushing. This
one probably explains many of the corruptions that have been
I have a corrupted multi-device file system that got corrupted ages
ago (as I recall, one of the drives stopped responding, causing btrfs
to panic). I am hoping to recover some of the data. For what it's
worth, here is the dmesg output from trying to mount the file system
on a 3.0 kernel:
device
On Mon, Nov 21, 2011 at 5:29 PM, René Vangsgaard
rene.vangsga...@gmail.com wrote:
Thank you for answering.
2) I get this error when mounting:
couldn't open because of unsupported option features (8).
fsck.btrfs: disk-io.c:679: open_ctree_fd: Assertion `!(1)' failed.
You're running an
This reverts commit a0c92a5871082c0aa6a7caae496e67a6e57bb0b6 (disable
space cache), as option nospace_cache was newly introduced in linux-3.2,
so we'll fail to mount btrfs in older kernels.
As an alternative fix, we just list subvolme names, don't assume
what ID numbers those subvolumes will
20 matches
Mail list logo
