On Mon, May 06, 2013 at 22:29 (+0200), Kai Krakow wrote:
Jan Schmidt list.bt...@jan-o-sch.net schrieb:
That one should be fixed in btrfs-next. If you can reliably reproduce the
bug I'd be glad to get a confirmation - you can probably even save putting
it on bugzilla then ;-)
I can
On Mon, May 06, 2013 at 23:20 (+0200), David Sterba wrote:
On Mon, May 06, 2013 at 09:14:17PM +0200, Jan Schmidt wrote:
--- a/include/uapi/linux/btrfs.h
+++ b/include/uapi/linux/btrfs.h
@@ -530,6 +530,7 @@ struct btrfs_ioctl_send_args {
struct
If you look the code carefully, you will see all the tree_mod_alloc()
has to use GFP_ATOMIC. However, the original code pass the wrong arg
gfp_t in some places, this dosen't cause any problems, because in the
tree_mod_alloc(), it ignores arg gfp_t and just use GFP_ATOMIC directly,
this is not
If qgroup_rescan worker is in progress, we should ignore
the extent that has not been dealt with qgroup_rescan worker,just
let them dealt later otherwise we may get wrong qgroup accounting.
However, we have checked this before find_all_roots() without spin_lock.
When doing qgroup accounting, we
On Tue, May 07, 2013 at 08:15 (+0200), Wang Shilong wrote:
If qgroup_rescan worker is in progress, we should ignore
the extent that has not been dealt with qgroup_rescan worker,just
let them dealt later otherwise we may get wrong qgroup accounting.
However, we have checked this before
On Tue, May 07, 2013 at 08:20 (+0200), Wang Shilong wrote:
If you look the code carefully, you will see all the tree_mod_alloc()
has to use GFP_ATOMIC. However, the original code pass the wrong arg
gfp_t in some places, this dosen't cause any problems, because in the
tree_mod_alloc(), it
We want this for btrfs_extent_same. Basically readpage and friends do their
own extent locking but for the purposes of dedupe, we want to have both
files locked down across a set of readpage operations (so that we can
compare data). Introduce this variant and a flag which can be set for
Hello Jan,
On Tue, May 07, 2013 at 08:20 (+0200), Wang Shilong wrote:
If you look the code carefully, you will see all the tree_mod_alloc()
has to use GFP_ATOMIC. However, the original code pass the wrong arg
gfp_t in some places, this dosen't cause any problems, because in the
Hello Jan,
On Tue, May 07, 2013 at 08:15 (+0200), Wang Shilong wrote:
If qgroup_rescan worker is in progress, we should ignore
the extent that has not been dealt with qgroup_rescan worker,just
let them dealt later otherwise we may get wrong qgroup accounting.
However, we have checked this
On Mon, 6 May 2013 23:11:20 +0200, David Sterba wrote:
Superblock is always 4k, but metadata blocks may be larger. We have to
use the appropriate block size when doing checksums, otherwise they're
wrong.
Signed-off-by: David Sterba dste...@suse.cz
---
btrfs-image.c | 27
I can get btrfs to throw a kernel bug easily by running btrfs fi
defrag on some files in 3.9.0:
May 7 01:57:33 caper kernel: [0.00] Linux version
3.9.0-030900-generic (apw@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro
4.6.3-1ubuntu5) ) #201304291257 SMP Mon Apr 29 16:58:15 UTC 2013
...
May
https://git.kernel.org/cgit/linux/kernel/git/mason/btrfs-progs.git/
I've just tried building btrfs-progs on i386 with a git pull from a few
minutes ago and I got the following warnings:
[CC] btrfs-list.o
btrfs-list.c: In function 'filter_by_parent':
btrfs-list.c:1183:34: warning: cast
Hello,
Thanks for reporting,
i will deal with this issue.
Thanks,
Wang
https://git.kernel.org/cgit/linux/kernel/git/mason/btrfs-progs.git/
I've just tried building btrfs-progs on i386 with a git pull from a few
minutes ago and I got the following warnings:
[CC] btrfs-list.o
The size parameter to btrfs_extend_item() is the number of bytes
to add to the item, not the size of the item after the operation
(like it is for btrfs_truncate_item(), there the size parameter
is not the number of bytes to take away, but the total size of
the item after truncation).
Fix it in the
On Mon, May 06, 2013 at 03:45:16PM -0400, Josef Bacik wrote:
On Wed, May 01, 2013 at 10:23:41AM -0600, Liu Bo wrote:
lock_extent/unlock_extent expect an exclusive end.
Can you make an xfstest for this so we can make sure we don't screw this up in
the future? Thanks,
Hi Josef,
I wish I
On Tue, May 07, 2013 at 11:25 (+0200), Elladan wrote:
I can get btrfs to throw a kernel bug easily by running btrfs fi
defrag on some files in 3.9.0:
Thanks for reporting. It's a known bug (that ought to be fixed before the 3.9
release in fact). You can either use btrfs-next or apply the
See the warnings below:
[CC] btrfs-list.o
btrfs-list.c: In function 'filter_by_parent':
btrfs-list.c:1183:34: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
[CC] cmds-subvolume.o
cmds-subvolume.c: In function 'cmd_subvol_show':
oops, i miswrite the patch titile Btrfs-progs to Btrfs..
Sorry my bad, will resend.
Thanks,
Wang
See the warnings below:
[CC] btrfs-list.o
btrfs-list.c: In function 'filter_by_parent':
btrfs-list.c:1183:34: warning: cast to pointer from integer of different size
On Mon, May 06, 2013 at 08:41:06PM -0400, Chris Mason wrote:
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 988b860..4de2351 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1690,15 +1690,19 @@ static int cleaner_kthread(void *arg)
struct btrfs_root
On Fri, May 03, 2013 at 04:37:41PM -0400, Chris Mason wrote:
Quoting Josef Bacik (2013-05-03 16:33:44)
On Mon, Apr 29, 2013 at 07:38:01AM -0600, David Sterba wrote:
After commit a65917156e34594 (Btrfs: stop using highmem for
extent_buffers) we don't need to call kmap_atomic anymore and
See the warnings below:
[CC] btrfs-list.o
btrfs-list.c: In function 'filter_by_parent':
btrfs-list.c:1183:34: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
[CC] cmds-subvolume.o
cmds-subvolume.c: In function 'cmd_subvol_show':
On Tue, May 07, 2013 at 06:52:49PM +0800, Liu Bo wrote:
On Mon, May 06, 2013 at 03:45:16PM -0400, Josef Bacik wrote:
Can you make an xfstest for this so we can make sure we don't screw this up
in
the future? Thanks,
I wish I could, but I don't know how to test this in a xfstest case...
This is not yet supported and causes crashes. One sad user reported
that it destroyed his filesystem.
One failure is in __btrfs_map_block+0xc1f calling kmalloc(0).
0x5f21f is in __btrfs_map_block (fs/btrfs/volumes.c:4923).
4918num_stripes = map-num_stripes;
4919
I hit this while working on fsck, I got some weird corruption where the number
of items was way higher than what would fit in a leaf, which would make things
blow up. This fixes the problem by catching it and returning an error so we
gracefully exit instead of segfaulting. Thanks,
Jan Schmidt list.bt...@jan-o-sch.net schrieb:
I can reliably reproduce it from two different approaches. I'd like to
only apply the commits fixing it. Can you name them here?
In git log order:
6ced2666 Btrfs: separate sequence numbers for delayed ref tracking and
tree mod log ef9120b1
How will it compare to bcache? I'm currently thinking about buying an SSD
but bcache requires some efforts in migrating the storage to use. And after
all those hassles I am even not sure if it would work easily with a dracut
generated initramfs.
On the side note: dm-cache, which is
Gabriel de Perthuis g2p.c...@gmail.com schrieb:
How will it compare to bcache? I'm currently thinking about buying an
SSD but bcache requires some efforts in migrating the storage to use.
And after all those hassles I am even not sure if it would work easily
with a dracut generated initramfs.
Do you plan to support deduplication on a finer grained basis than file
level? As an example, in the end it could be interesting to deduplicate 1M
blocks of huge files. Backups of VM images come to my mind as a good
candidate. While my current backup script[1] takes care of this by using
On Tue, 07 May 2013 23:58:08 +0200, Kai Krakow wrote:
Gabriel de Perthuis g2p.c...@gmail.com schrieb:
On the side note: dm-cache, which is already in-kernel, do not need to
reformat backing storage.
On the other hand dm-cache is somewhat complex to assemble, and letting
the system
Gabriel de Perthuis g2p.c...@gmail.com schrieb:
It sounds simple, and was sort-of prompted by the new syscall taking
short ranges, but it is tricky figuring out a sane heuristic (when to
hash, when to bail, when to submit without comparing, what should be the
source in the last case), and
Kai Krakow hurikhan77+bt...@gmail.com schrieb:
Gabriel de Perthuis g2p.c...@gmail.com schrieb:
It sounds simple, and was sort-of prompted by the new syscall taking
short ranges, but it is tricky figuring out a sane heuristic (when to
hash, when to bail, when to submit without comparing,
On Wed, 08 May 2013 01:04:38 +0200, Kai Krakow wrote:
Gabriel de Perthuis g2p.c...@gmail.com schrieb:
It sounds simple, and was sort-of prompted by the new syscall taking
short ranges, but it is tricky figuring out a sane heuristic (when to
hash, when to bail, when to submit without comparing,
Kai Krakow hurikhan77+bt...@gmail.com schrieb:
I can reliably reproduce it from two different approaches. I'd like to
only apply the commits fixing it. Can you name them here?
In git log order:
6ced2666 Btrfs: separate sequence numbers for delayed ref tracking and
tree mod log ef9120b1
33 matches
Mail list logo
