On Tue, Apr 23, 2013 at 11:18:19AM -0500, Jon Nelson wrote:
On Tue, Apr 23, 2013 at 10:03 AM, Liu Bo bo.li@oracle.com wrote:
Can you please show us where it BUG_ON(or logs) when mounting with -o
recovery?
(the stack info below seems not to be a resulf of '-o recovery'?)
I have
On Tue, Apr 23, 2013 at 08:00:27PM +0200, Jan Schmidt wrote:
Sequence numbers for delayed refs have been introduced in the first version
of the qgroup patch set. To solve the problem of find_all_roots on a busy
file system, the tree mod log was introduced. The sequence numbers for that
were
On Tue, Apr 23, 2013 at 02:20:22PM -0400, Josef Bacik wrote:
We kept leaking extent buffers when mounting a broken file system and it turns
out it's because not everybody uses read_tree_block properly. You need to
check
and make sure the extent_buffer is uptodate before you use it. This
On Wed, April 24, 2013 at 10:12 (+0200), Liu Bo wrote:
On Tue, Apr 23, 2013 at 08:00:27PM +0200, Jan Schmidt wrote:
Sequence numbers for delayed refs have been introduced in the first version
of the qgroup patch set. To solve the problem of find_all_roots on a busy
file system, the tree mod
On Tue, Apr 23, 2013 at 02:48:54PM -0400, Josef Bacik wrote:
If we fail to load block groups halfway through we can leave extent_state's on
the excluded tree. This is because we just lookup the supers and add them to
the excluded tree regardless of which block group we are looking at
Hello Jan,
[snip]
+/*
+ * returns 0 on error, 0 when more leafs are to be scanned.
+ * returns 1 when done, 2 when done and FLAG_INCONSISTENT was cleared.
+ */
+static int
+qgroup_rescan_leaf(struct qgroup_rescan *qscan, struct btrfs_path *path,
+struct btrfs_trans_handle
I'm having lots of problems with wrong checksums on the most recent
kernels. Note that this is not a regression as far as I know, just
more pronounced now than before (the increase in severity might be due
to changes in my setup).
I see that this was discussed on the ML a few months back, but it
Hi,
I scrubbed a BTRFS volume (mounted as a VFS root) and got several
errors. However I am not able to make btrfs print the path of the
corrupted files...
E.g. kernel log gives :
[51078.682876] btrfs: unable to fixup (regular) error at logical
51241746432 on dev /dev/root
[51078.683013]
On Tue, Apr 23, 2013 at 03:57:25PM -0500, Eric Sandeen wrote:
vger ate my giant rename-files patch; here's the makefile bit, and
hopefully the rename-diffs at the end are something that git
knows how to apply? TBH I've never tried that before.
Yes it works, eg. the rename from btrsfck.c -
On Sun, Apr 21, 2013 at 05:22:37PM -0500, Eric Sandeen wrote:
This gets rid of a lot of the cut and pasted rules for
each individual command, and as an added bonus makes it
easy to build any btrfs-$FOO statically as well, i.e.
# make btrfs-convert.static
Nice!
+# keep intermediate files
On Wed, Apr 24, 2013 at 02:57:40AM -0600, Liu Bo wrote:
On Tue, Apr 23, 2013 at 02:48:54PM -0400, Josef Bacik wrote:
If we fail to load block groups halfway through we can leave extent_state's
on
the excluded tree. This is because we just lookup the supers and add them
to
the
On Mon, Apr 22, 2013 at 11:01:09AM -0500, Eric Sandeen wrote:
Maybe one for Arne to answer? Yeah, I don't see it in the manpage
or in userspace, so *shrug* where is the design?
Scrub can be started on one device, cancel is just part of the command set.
$ ./btrfs scrub cancel --help
On Tue, Apr 23, 2013 at 12:00:27PM -0600, Jan Schmidt wrote:
Sequence numbers for delayed refs have been introduced in the first version
of the qgroup patch set. To solve the problem of find_all_roots on a busy
file system, the tree mod log was introduced. The sequence numbers for that
were
On Wed, Apr 24, 2013 at 02:17:48AM -0600, Liu Bo wrote:
On Tue, Apr 23, 2013 at 02:20:22PM -0400, Josef Bacik wrote:
We kept leaking extent buffers when mounting a broken file system and it
turns
out it's because not everybody uses read_tree_block properly. You need to
check
and make
On Wed, April 24, 2013 at 15:04 (+0200), Josef Bacik wrote:
On Tue, Apr 23, 2013 at 12:00:27PM -0600, Jan Schmidt wrote:
Sequence numbers for delayed refs have been introduced in the first version
of the qgroup patch set. To solve the problem of find_all_roots on a busy
file system, the tree
On Wed, Apr 24, 2013 at 07:25:09AM -0600, Jan Schmidt wrote:
On Wed, April 24, 2013 at 15:04 (+0200), Josef Bacik wrote:
On Tue, Apr 23, 2013 at 12:00:27PM -0600, Jan Schmidt wrote:
Sequence numbers for delayed refs have been introduced in the first version
of the qgroup patch set. To solve
On Wed, Apr 24, 2013 at 1:24 PM, Tom Gundersen t...@jklm.no wrote:
I'm having lots of problems with wrong checksums on the most recent
kernels. Note that this is not a regression as far as I know, just
more pronounced now than before (the increase in severity might be due
to changes in my
On Wed, Apr 24, 2013 at 09:00:16AM -0400, Josef Bacik wrote:
On Wed, Apr 24, 2013 at 02:57:40AM -0600, Liu Bo wrote:
On Tue, Apr 23, 2013 at 02:48:54PM -0400, Josef Bacik wrote:
If we fail to load block groups halfway through we can leave
extent_state's on
the excluded tree. This is
On Tue, Apr 23, 2013 at 10:54:53AM -0400, Josef Bacik wrote:
A user sent me a btrfs-image that was panicing because of some corruption.
This
is because we pass in a bogus value to btrfs_num_copies, and it panics.
Instead
just return 1. We only call btrfs_num_copies to see if there are
On Wed, Apr 24, 2013 at 08:43:21AM -0600, Liu Bo wrote:
On Wed, Apr 24, 2013 at 09:00:16AM -0400, Josef Bacik wrote:
On Wed, Apr 24, 2013 at 02:57:40AM -0600, Liu Bo wrote:
On Tue, Apr 23, 2013 at 02:48:54PM -0400, Josef Bacik wrote:
If we fail to load block groups halfway through we can
On Tue, Apr 23, 2013 at 11:31:39AM -0400, Josef Bacik wrote:
With a users corrupted fs I was getting weird behavior and panics and it turns
out it was because one of his tree blocks had a bogus header level. So add
this
to the sanity checks in the endio handler for tree blocks. Thanks,
On Tue, Apr 23, 2013 at 11:09:54AM -0400, Josef Bacik wrote:
This work is done by btrfs_free_path() anyway so there's no need for this
duplicate work. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
Reviewed-by: David Sterba dste...@suse.cz
--
To unsubscribe from this list: send the
On Wed, April 24, 2013 at 13:00 (+0200), Wang Shilong wrote:
Hello Jan,
[snip]
+/*
+ * returns 0 on error, 0 when more leafs are to be scanned.
+ * returns 1 when done, 2 when done and FLAG_INCONSISTENT was cleared.
+ */
+static int
+qgroup_rescan_leaf(struct qgroup_rescan *qscan,
On Tue, Apr 23, 2013 at 02:20:22PM -0400, Josef Bacik wrote:
We kept leaking extent buffers when mounting a broken file system and it turns
out it's because not everybody uses read_tree_block properly. You need to
check
and make sure the extent_buffer is uptodate before you use it. This
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/relocation.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index c22ccfe..e85be23 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2878,8 +2878,11
Sequence numbers for delayed refs have been introduced in the first version
of the qgroup patch set. To solve the problem of find_all_roots on a busy
file system, the tree mod log was introduced. The sequence numbers for that
were simply shared between those two users.
However, at one point in
i am looking for a way to query btrfs filesystems for all options used to create the filesystem
(i.e. data, leafsize, label, metadata, nodesize, sectorsize) in an effort to be able to record this
information and be able to recreate the filesystem with the same attributes if necessary.
i see
This is the same as the fix from commit
Btrfs: fix bad extent logging
but for O_DIRECT. I missed this when I fixed the problem originally, we were
still using the em for the orig_start and orig_block_len, which would be the
merged extent. We need to use the actual extent from the on disk file
We can run the tree logging recovery or the orphan cleanup on mount, so we'll
end up looking up a random fs tree in the meantime. So we need to clean this up
so we don't leave extent buffers hanging around on the cache. With this patch
we no longer leak extent buffers on failure to mount.
We need to check the return value of the commit in case something goes wrong,
otherwise we could end up going down the line and doing more stuff (like orphan
cleanup) before we notice we should have errored out. We need to do this before
we free up the log_tree_root since the caller will handle
This is just obnoxious. Just print a message, abort the transaction, and return
an error. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/extent-tree.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/extent-tree.c
We can just look up the extent_buffers for the range and free stuff that way.
This makes the cleanup a bit cleaner and we can make sure to evict the
extent_buffers pretty quickly by marking them as stale. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/disk-io.c | 41
I think actual userland tools should be able to do what you want;
leafsize, nodesize, sectorsize: btrfs-show-super /dev/dm-6
label: blkid /dev/dm-6
data, metadata: btrfs filesystem df /
# btrfs-show-super /dev/dm-6
superblock: bytenr=65536, device=/dev/dm-6
On Wed, Apr 24, 2013 at 01:00:02PM -0700, Rich Turner wrote:
i am looking for a way to query btrfs filesystems for all options used to
create the filesystem (i.e. data, leafsize, label, metadata, nodesize,
sectorsize) in an effort to be able to record this information and be able
to recreate
# btrfs subvol list /home
ERROR: Failed to lookup path for root 0 - No such file or directory
# btrfs subvol list /home
ID 269 gen 449406 top level 5 path backup
...
I'm getting errors from the btrfs subvol list command as above, I'm running
the Debian 3.8.3 kernel. The errors occur after
Hello,
This problem has been fixed.Would you please try the latest btrfs-progs,
and see it this problem happens again.
Btrfs-progs commitid: 64edc851da59c47b92ee6830101be0854add7f09 fix this problem.
The latest btrfs-progs url:
http://git.kernel.org/cgit/linux/kernel/git/mason/btrfs-progs.git
Hello Jan,
On Wed, April 24, 2013 at 13:00 (+0200), Wang Shilong wrote:
Hello Jan,
[snip]
+/*
+ * returns 0 on error, 0 when more leafs are to be scanned.
+ * returns 1 when done, 2 when done and FLAG_INCONSISTENT was cleared.
+ */
+static int
+qgroup_rescan_leaf(struct qgroup_rescan
On Wed, Apr 24, 2013 at 10:48:09AM -0400, Josef Bacik wrote:
On Wed, Apr 24, 2013 at 08:43:21AM -0600, Liu Bo wrote:
On Wed, Apr 24, 2013 at 09:00:16AM -0400, Josef Bacik wrote:
On Wed, Apr 24, 2013 at 02:57:40AM -0600, Liu Bo wrote:
On Tue, Apr 23, 2013 at 02:48:54PM -0400, Josef Bacik
38 matches
Mail list logo
