On Wed, Mar 13, 2013 at 02:01:58PM -0500, Eric Sandeen wrote:
Run basic btrfs information commands in various ways, performing
sanity tests of: filesystem show, label, sync, and device stats
(sync is included just because it's simple). These are mostly
just smoke tests, although for example
On Wed, Mar 13, 2013 at 03:31:19PM -0400, Chris Mason wrote:
Thanks for finding this and writing up the patch. Can we please change
it to ignore the crc if the transid is from mkfs?
We can fix the mkfs part, but anything that goes through
commit_transaction (and write_all_supers) will fail to
On Thu, Mar 14, 2013 at 02:59:51PM -0700, Darrick J. Wong wrote:
On Tue, Mar 12, 2013 at 05:41:13PM +0800, Liu Bo wrote:
On Tue, Mar 12, 2013 at 10:32:09AM +0100, Johannes Hirte wrote:
On Tue, 12 Mar 2013 09:39:35 +0800
Liu Bo bo.li@oracle.com wrote:
Hi Johannes,
maybe a little more commit log would be good?
So here is what confuses me now. :)
*every* caller of btrfs_read_dev_super() is now called with
0 for the flags variable, so it never reads the backup
under any circumstance.
If it's always called w/ 0, what is the point of the argument?
Is
On Tue, Mar 12, 2013 at 02:01:24PM -0400, Chris Mason wrote:
Please go back to just 3.9-rc2 and see if you can trigger it. Josef put
his skinny extents into btrfs-next/master, which is pretty exciting but
may be related to these failures.
I'm unable to reproduce here so far.
Me neither,
On Mon, Mar 11, 2013 at 09:15:44PM +0100, Remco Hosman wrote:
first, i did the following: `btrfs val start -dconvert=raid5,usage=1` to
convert the mostly empty chunks.
This resulted in a lot of allocated space (10's of gigs), with only a few 100
meg used.
Matches my expectation, converting
On Fri, Mar 15, 2013 at 06:07:08AM -0600, David Sterba wrote:
On Tue, Mar 12, 2013 at 02:01:24PM -0400, Chris Mason wrote:
Please go back to just 3.9-rc2 and see if you can trigger it. Josef put
his skinny extents into btrfs-next/master, which is pretty exciting but
may be related to these
We keep hitting bugs in the tree log replay because btrfs_remove_free_space
doesn't account for some corner case. So add a bunch of tests to try and fully
test btrfs_remove_free_space since the only time it is called is during tree log
replay. These tests all finish successfully, so as we find
Yep sorry. I figure its always a race in numbers do I don't bother with fixing
them up. Should I?
On Mar 15, 2013, at 5:16 AM, Dave Chinner da...@fromorbit.com wrote:
On Wed, Mar 13, 2013 at 02:01:58PM -0500, Eric Sandeen wrote:
Run basic btrfs information commands in various ways,
Signed-off-by: Matias Bjørling m...@bjorling.me
---
man/mkfs.btrfs.8.in | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8.in
index 41163e0..db8c57c 100644
--- a/man/mkfs.btrfs.8.in
+++ b/man/mkfs.btrfs.8.in
@@ -37,7 +37,7 @@
On 03/15/2013 08:46 AM, Eric Sandeen wrote:
Yep sorry. I figure its always a race in numbers do I don't bother with fixing
them up. Should I?
Eric,
I was going to revert and resubmit as test 306, is that OK with you?
On Mar 15, 2013, at 5:16 AM, Dave Chinner da...@fromorbit.com wrote:
On Mar 15, 2013, at 9:23 AM, Rich Johnston rjohns...@sgi.com wrote:
On 03/15/2013 08:46 AM, Eric Sandeen wrote:
Yep sorry. I figure its always a race in numbers do I don't bother with
fixing them up. Should I?
Eric,
I was going to revert and resubmit as test 306, is that OK with you?
Users report that an extent map's list is still linked when it's actually
going to be freed from cache.
The story is that
a) when we're going to drop an extent map and may split this large one into
smaller ems, and if this large one is flagged as EXTENT_FLAG_LOGGING which means
that it's on the
On Tue, Mar 12, 2013 at 11:42:50AM -0500, Eric Sandeen wrote:
Define a new _defrag_dir() helper which just runs noisy/debug
dir defrag for ext4 and/or btrfs as well, and use that in 222
instead of hardcoded xfs_fsr.
Dir defrag on btrfs does not recurse in the given directory to defrag
all
On Wed, Feb 27, 2013 at 12:52:50PM -0800, Alex Elsayed wrote:
Also, in talking on IRC with Hugo Mills he helped me realize another issue -
specifically, that a.) DIO to compressed data falls back to buffered IO, and
b.) (at least according to the wiki) the compress_force mount option takes
On 03/15/2013 09:55 AM, David Sterba wrote:
On Tue, Mar 12, 2013 at 11:42:50AM -0500, Eric Sandeen wrote:
Define a new _defrag_dir() helper which just runs noisy/debug
dir defrag for ext4 and/or btrfs as well, and use that in 222
instead of hardcoded xfs_fsr.
Dir defrag on btrfs does not
On 3/15/13 11:03 AM, Rich Johnston wrote:
On 03/15/2013 09:55 AM, David Sterba wrote:
On Tue, Mar 12, 2013 at 11:42:50AM -0500, Eric Sandeen wrote:
Define a new _defrag_dir() helper which just runs noisy/debug
dir defrag for ext4 and/or btrfs as well, and use that in 222
instead of hardcoded
We can't use ext2_dir_entry_2 typecast on big endian machines directly.
The bytes do not get converted during extX block read due to missing
flag EXT2_DIRBLOCK_V2_STRUCT passed down to ext2fs_read_dir_block4 from
ext2fs_process_dir_block. Fixing on the ext2 side needs updating callers
and (maybe)
On 3/15/13 7:03 AM, Anand Jain wrote:
maybe a little more commit log would be good?
So here is what confuses me now. :)
*every* caller of btrfs_read_dev_super() is now called with
0 for the flags variable, so it never reads the backup
under any circumstance.
If it's always called w/
Eric,
Thanks once more for the patch. Once I finally got the correct version
of mkfs.btrfs this looks good.
Reviewed-by: Rich Johnston rjohns...@sgi.com
Interesting that the default make install of btrfs-progs did not install
over my btrfsprogs rpm.
Was running SLES11 SP2 with
This patch has been commited.
Thanks
--Rich
commit 99eb53da9c08148132cdf3cd401b248e6a0d96c5
Author: Eric Sandeen sand...@redhat.com
Date: Wed Mar 13 16:01:00 2013 +
xfstests: enable test 032 (mkfs overwrite) for btrfs
Now that btrfs has an -f arg, we can test that it doesn't
On 3/15/13 12:07 PM, Rich Johnston wrote:
Eric,
Thanks once more for the patch. Once I finally got the correct version of
mkfs.btrfs this looks good.
Reviewed-by: Rich Johnston rjohns...@sgi.com
Interesting that the default make install of btrfs-progs did not install over
my
On Tue, Mar 12, 2013 at 06:53:25PM +0100, David Sterba wrote:
On Tue, Mar 12, 2013 at 03:44:11PM +, Hugo Mills wrote:
+btrfs-find-root.static: $(static_objects) $(libs) find-root.static.o
I've noticed that the (newly added) mkfs.btrfs.static target does not
depend on $(libs) and this is
Koen,
Thanks for submitting several new tests. Are you still interested in
these tests and willing to address the comments?
Thanks
--Rich
Thanks for the reviews Eric and Dave.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to
This fixes up the progs to properly deal with skinny metadata. This adds the -x
option to mkfs and btrfstune for enabling the skinny metadata option. This also
makes changes to fsck so it can properly deal with the skinny metadata entries.
Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
On Fri, Mar 15, 2013 at 02:52:29PM -0400, Josef Bacik wrote:
This fixes up the progs to properly deal with skinny metadata. This adds the
-x
option to mkfs and btrfstune for enabling the skinny metadata option. This
also
makes changes to fsck so it can properly deal with the skinny
On Fri, Mar 15, 2013 at 07:13:30AM -0600, Josef Bacik wrote:
On Fri, Mar 15, 2013 at 06:07:08AM -0600, David Sterba wrote:
On Tue, Mar 12, 2013 at 02:01:24PM -0400, Chris Mason wrote:
Please go back to just 3.9-rc2 and see if you can trigger it. Josef put
his skinny extents into
This fixes up the progs to properly deal with skinny metadata. This adds the -x
option to mkfs and btrfstune for enabling the skinny metadata option. This also
makes changes to fsck so it can properly deal with the skinny metadata entries.
Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
On Fri, Mar 15, 2013 at 10:46:39PM +0800, Liu Bo wrote:
Users report that an extent map's list is still linked when it's actually
going to be freed from cache.
The story is that
a) when we're going to drop an extent map and may split this large one into
smaller ems, and if this large one
We just free the log root after we set it up when we open a ctree in the tools.
This isn't nice, it makes double free's and leaks eb's, makes segfaults with
btrfs-image. So fix this to be correct, and fix the cleanup if the buffer is
not uptodate. With this fix I no longer segfault trying to do
30 matches
Mail list logo
