1) Right now scrub_stripe() is looping in some unnecessary cases:
* when the found extent item's objectid has been out of the dev extent's range
but we haven't finish scanning all the range within the dev extent
* when all the items has been processed but we haven't finish scanning all the
rang
On Thu, Apr 25, 2013 at 07:18:59PM +0200, David Sterba wrote:
> On Thu, Apr 18, 2013 at 04:42:18PM +0200, David Sterba wrote:
> > [64394.422743] BUG: unable to handle kernel NULL pointer dereference at
> > 0078
> > [64394.426716] RIP: 0010:[] []
> > btrfs_search_slot+0xbf/0x9e0 [btrf
On Fri, Apr 26, 2013 at 02:39:29PM -0400, Josef Bacik wrote:
> On Fri, Apr 26, 2013 at 11:11:18AM -0600, Liu Bo wrote:
> > From: root
> >
>
> May want to set your git.email.
>
> Josef
ah, will get it fix soon.
thanks,
liubo
--
To unsubscribe from this list: send the line "unsubscribe linux-bt
Hey Josef,
Thanks for looking into this further!That is about the same
results that I was seeing, though I didn't test it with just one
drive.. only with all 12 drives in my jbod. I will do a test with
just one disk, and see if I also get the same results.
Let me know if you also see the sam
On Fri, Apr 26, 2013 at 06:32:14PM -0400, Josef Bacik wrote:
> On Fri, Apr 26, 2013 at 04:05:22PM -0600, Dave Chinner wrote:
> > On Fri, Apr 26, 2013 at 03:31:01PM -0400, Josef Bacik wrote:
> > > On Thu, Apr 25, 2013 at 08:12:14PM -0600, Dave Chinner wrote:
> > > > > Ok so I think I'll just make th
On Fri, Apr 26, 2013 at 04:05:22PM -0600, Dave Chinner wrote:
> On Fri, Apr 26, 2013 at 03:31:01PM -0400, Josef Bacik wrote:
> > On Thu, Apr 25, 2013 at 08:12:14PM -0600, Dave Chinner wrote:
> > > > Ok so I think I'll just make this test do all the iterations of the
> > > > fsync tester
> > > > wi
On Fri, Apr 26, 2013 at 03:31:01PM -0400, Josef Bacik wrote:
> On Thu, Apr 25, 2013 at 08:12:14PM -0600, Dave Chinner wrote:
> > > Ok so I think I'll just make this test do all the iterations of the fsync
> > > tester
> > > with and without --nolockfs, since without --nolockfs I'm still seeing
>
cmds-check.c contains the only caller of btrfs_fsck_reinit_root;
moving it to the caller's source file gets ctree.c a little
closer to kernelspace, although it does require exporting
add_root_to_dirty_list(), which is not done in kernelspace.
Signed-off-by: Eric Sandeen
---
cmds-check.c | 43 +
Remove some commented-out & #if 0'd code:
* close_blocks()
* btrfs_drop_snapshot()
* btrfs_realloc_node()
* btrfs_find_dead_roots()
There are still some #if 0'd functions in there, but I'm hedging
on those for now, they have been copied to cmds-check.c and I want
to see if they can be brough
cmds-restore.c cut & paste btrfs_next_leaf w/ a little
extra; we can just call btrfs_next_leaf from there, after
the bit of additional pre-checking that it does.
Strangely, every caller in restore checks for a negative
return as an error, but the copy never returned negative.
Calling btrfs_next_le
div_factor has been implemented for two times, cleanup it.
And I move them into a independent file named math.h because they are
common math functions.
[Eric Sandeen: port kernel commit 3fed40c to userspace]
Signed-off-by: Miao Xie
Signed-off-by: Eric Sandeen
---
extent-tree.c | 10 +
extent_ref_type() contains inconsequential differences between
kernelspace and userspace, and has since the initial commits
to each. Just make userspace look like kernelspace.
Signed-off-by: Eric Sandeen
---
extent-tree.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff
The code path should not reach there. Remove it.
[Eric Sandeen: port kernel commit 3fed40c to userspace]
Signed-off-by: Wang Sheng-Hui
Signed-off-by: Eric Sandeen
---
ctree.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/ctree.c b/ctree.c
index b7b12a3..7257e6f
Otherwise we can execced the array bound of path->slots[].
[Eric Sandeen: port kernel commit a05a9bb to userspace]
Signed-off-by: Li Zefan
Signed-off-by: Eric Sandeen
---
ctree.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/ctree.c b/ctree.c
index 0311e25..
A first round of small, hopefully obviously-correct and/or no-op
patches that start to make the userspace copies of kernelspace code
look a bit more similar.
Many of these are direct ports from userspace, a couple others
are just my cleanups of various bits here and there.
There'll be a fair bit
btrfs_init_path was initially used when the path objects were on the
stack. Now all the work is done by btrfs_alloc_path and btrfs_init_path
isn't required.
This patch removes it, and just uses kmem_cache_zalloc to zero out the object.
[Eric Sandeen: port kernel commit e00f730 to userspace]
(No
Files with only #include directives are boring. :)
This is just a leftover after the move to the btrfs tool.
Signed-off-by: Eric Sandeen
---
btrfs-defrag.c | 39 ---
1 files changed, 0 insertions(+), 39 deletions(-)
delete mode 100644 btrfs-defrag.c
diff
I've not been able to pull Chris's for-linus branch into a recent kernel for a
few weeks now (since 3.8.5). Is for-linus still compatible with the latest
stable releases? If not, what is the preferred way of running the latest
btrfs code?
$ git clone linux linux-3.8.10
$ cd linux-3.8.10
$ git
On Thu, Apr 25, 2013 at 08:12:14PM -0600, Dave Chinner wrote:
> On Thu, Apr 25, 2013 at 09:32:37PM -0400, Josef Bacik wrote:
> > On Thu, Apr 25, 2013 at 07:08:29PM -0600, Dave Chinner wrote:
> > > On Thu, Apr 25, 2013 at 08:24:04PM -0400, Josef Bacik wrote:
> > > > On Thu, Apr 25, 2013 at 04:45:56P
This test sets up a dm flakey target and then runs my fsync tester I've been
using to verify btrfs's fsync() is working properly. It will create a dm flakey
device, mount it, run my test, make the flakey device start dropping writes, and
then unmount the fs. Then we mount it back up and make sure
test 284 had... some issues.
First, it took so long nobody ran it; so shorten the extent
count by a factor of about 100.
Having fixed that, we see failures in 2 cases; when start or
len is -1, but the golden output file didn't have error
output, as if they should pass.
I'm going to argue that th
On Fri, Apr 26, 2013 at 11:11:18AM -0600, Liu Bo wrote:
> From: root
>
May want to set your git.email.
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-i
On Fri, Apr 26, 2013 at 03:05:42PM +0200, David Sterba wrote:
> On Thu, Apr 25, 2013 at 01:48:07PM -0400, Josef Bacik wrote:
> > + printk(KERN_ERR "release %Lu for %p\n", trans->bytes_reserved, trans);
>
> for (i=0; i<100; i++)
> say "printing u64 type requires typecast to unsigned long lo
> @@ -2906,8 +2909,9 @@ int relocate_tree_blocks(struct btrfs_trans_handle
> *trans,
> out:
> err = finish_pending_nodes(trans, rc, path, err);
>
> +out_free_path:
> btrfs_free_path(path);
> -out_path:
> +out_free_blocks:
> free_block_list(blocks);
> return err;
> }
> -
From: root
1) Right now scrub_stripe() is looping in some unnecessary cases:
* when the found extent item's objectid has been out of the dev extent's range
but we haven't finish scanning all the range within the dev extent
* when all the items has been processed but we haven't finish scanning a
Liu Bo created test 284 for xfstests to exercise btrfs defragmentation.
One test sends an argument including "-s -1" meaning "start at negative one"
That's failing today, because parse_size now rejects negative numbers.
(that might be something to fix on its own, since length = (u64)-1
might impl
On Thu, Apr 25, 2013 at 06:04:52PM +0200, Jan Schmidt wrote:
> @@ -1520,6 +1524,13 @@ int btrfs_run_qgroups(struct btrfs_trans_handle *trans,
> if (ret)
> fs_info->qgroup_flags |= BTRFS_QGROUP_STATUS_FLAG_INCONSISTENT;
>
> + if (!ret && start_rescan_worker) {
> +
There's a theoretical possibility of reading stale (or even more
theoretically, freed) data from DEV_INFO ioctl when the device would
disappear between an early mutex unlock and data being copied from the
device structure.
Signed-off-by: David Sterba
---
fs/btrfs/ioctl.c |2 +-
1 files chang
It's unused since 0b32f4bbb423f02ac.
Signed-off-by: David Sterba
---
fs/btrfs/disk-io.c |8 +---
fs/btrfs/extent_io.c | 13 +
fs/btrfs/extent_io.h |2 +-
3 files changed, 7 insertions(+), 16 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index fa84
On Apr 26, 2013, at 3:35 AM, Jan Schmidt wrote:
> On Fri, April 26, 2013 at 07:29 (+0200), Eric Sandeen wrote:
>> Tests after 276 were failing because the background fsstress
>> hadn't quit prior to exit, devices couldn't be unmounted, etc.
>
> I don't see how that would happen. Any further insi
On Thu, Apr 25, 2013 at 01:48:07PM -0400, Josef Bacik wrote:
> + printk(KERN_ERR "release %Lu for %p\n", trans->bytes_reserved, trans);
for (i=0; i<100; i++)
say "printing u64 type requires typecast to unsigned long long"
--
To unsubscribe from this list: send the line "unsubscribe lin
Signed-off-by: David Sterba
---
fs/btrfs/relocation.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index c22ccfe..39b7b64 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2864,7 +2864,7 @@ int relo
On Fri, 26 Apr 2013 17:39:16 +0800, Anand Jain wrote:
>
> As showed in the previous email in this thread, we need to get
> the error string from the kernel to the cli to improve the
> usability of the product.
> As also said, I was looking at two way which I think we could
> do this, here I t
adds a parameter in the ioctl arg struct to carry the error string
Signed-off-by: Anand Jain
---
fs/btrfs/ioctl.c | 42 +++---
fs/btrfs/volumes.c | 29 +++--
fs/btrfs/volumes.h | 2 +-
include/uapi/linux/btrfs
add another parameter to the ioctl arg structure to carry the error string
Signed-off-by: Anand Jain
---
cmds-device.c | 13 +
ioctl.h | 9 -
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/cmds-device.c b/cmds-device.c
index 41e79d3..3cf96db 100644
---
As showed in the previous email in this thread, we need to get
the error string from the kernel to the cli to improve the
usability of the product.
As also said, I was looking at two way which I think we could
do this, here I take the 2nd approach which is to pass the error
string though th
On Fri, 26 Apr 2013 16:58:18 +0800, Miao Xie wrote:
> On tue, 23 Apr 2013 16:54:35 -0400, Josef Bacik wrote:
>> On Wed, Apr 03, 2013 at 03:14:56AM -0600, Miao Xie wrote:
>>> Using the structure btrfs_sector_sum to keep the checksum value is
>>> unnecessary, because the extents that btrfs_sector_sum
On tue, 23 Apr 2013 16:54:35 -0400, Josef Bacik wrote:
> On Wed, Apr 03, 2013 at 03:14:56AM -0600, Miao Xie wrote:
>> Using the structure btrfs_sector_sum to keep the checksum value is
>> unnecessary, because the extents that btrfs_sector_sum points to are
>> continuous, we can find out the expecte
On Fri, April 26, 2013 at 07:29 (+0200), Eric Sandeen wrote:
> Tests after 276 were failing because the background fsstress
> hadn't quit prior to exit, devices couldn't be unmounted, etc.
I don't see how that would happen. Any further insight?
> Just use the same trick as generic/068 does, and u
Adrien Dessemond wrote (ao):
> 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
> 512417464
40 matches
Mail list logo
