Remove "device show" from btrfs man page as it's not supported by the
btrfs utility.
---
man/btrfs.8.in | 2 --
1 file changed, 2 deletions(-)
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 9222580..e663da2 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -33,8 +33,6 @@ btrfs \- control a
Sure, I'll make another patch.
Thanks
Simon
On 2013/1/9 15:14, Jeff Liu wrote:
Hi Simon,
For the next time when you post btrfs-progs related patches, please
indicate it with a suffix "Btrfs-progs: " on the subject.
Thanks,
-Jeff
On 01/09/2013 02:46 PM, Simon Xu wrote:
Remove "device show" fr
Hi Simon,
For the next time when you post btrfs-progs related patches, please
indicate it with a suffix "Btrfs-progs: " on the subject.
Thanks,
-Jeff
On 01/09/2013 02:46 PM, Simon Xu wrote:
> Remove "device show" from btrfs man page as it's not supported by the
> btrfs utility.
> ---
> man/btrfs
Remove "device show" from btrfs man page as it's not supported by the
btrfs utility.
---
man/btrfs.8.in | 2 --
1 file changed, 2 deletions(-)
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 9222580..e663da2 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -33,8 +33,6 @@ btrfs \- control a
On Tue, Jan 08, 2013 at 06:26:27PM +0100, David Sterba wrote:
> On Tue, Jan 08, 2013 at 09:30:54AM +0100, David Sterba wrote:
> > On Tue, Jan 08, 2013 at 10:46:38AM +0800, Liu Bo wrote:
> > > Hmm, not always here, lockend = inode->i_size - 1, so lockend % 2 == 1
> > > may not
> > > be true.
> >
>
Hello,
btrfs-progs is at 91d9eec1ff044394f2b98ee7fcb76713dd33b994
kernel is at 3.6.11-1-ARCH
Thanks.
On Wed, Jan 9, 2013 at 10:01 AM, Randy Barlow
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/08/2013 12:40 AM, Jordan Windsor wrote:
>> If you need anymore information please a
On 2013-01-08 11:28 +0800, Liu Bo wrote:
> And for the fragmentation, do you mean 'filefrag'?
I was for something that would show how the data branches off across
different snapshots, --reflink copies etc.
filefrag looks interesting, thanks.
--
To unsubscribe from this list: send the line "unsubs
Remove the owner variable as well as it related stuff.
owner is meaningless in btrfs_new_inode() context, clean it out.
Signed-off-by: Jie Liu
---
fs/btrfs/inode.c |6 --
1 file changed, 6 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 95542a1..f56eae1 100644
---
Fix a sparse warning:
fs/btrfs/delayed-ref.c:236:1: warning: ‘inline’ is not at beginning of
declaration [-Wold-style-declaration]
Signed-off-by: Jie Liu
---
fs/btrfs/delayed-ref.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/delayed-ref.c b/fs/btrfs/delayed-r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/08/2013 12:40 AM, Jordan Windsor wrote:
> If you need anymore information please ask.
Kernel and btrfs-tools versions?
- --
R
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.
External software wanting to use the functionality provided by the btrfs
send ioctl has a hard time doing so without replicating tons of work. Of
particular interest are functions like btrfs_read_and_process_send_stream()
and subvol_uuid_search(). As that functionality requires a bit more than
just
send-test.c links against libbtrfs and uses the send functionality provided
to decode and print a send stream to the console. We use the
BTRFS_SEND_FLAG_NO_FILE_DATA flag as actual file data is never needed for
this.
Signed-off-by: Mark Fasheh
---
Makefile|5 +-
send-test.c | 458 ++
The flag and command are synced from kernel to user. Also, this patch adds a
callback for the BTRFS_SEND_C_UPDATE_EXTENT in struct btrfs_send_ops.
read_and_process_cmd() is updated to decode BTRFS_SEND_C_UPDATE_EXTENT and
send the values through the right callback. I did not add a callback
definiti
Hi,
The following 3 patches make changes to btrfs-progs in order to
provide support for external software that wants to make use of the
excellent btrfs send ioctl.
The first patch introduces support for the BTRFS_SEND_FLAG_NO_FILE_DATA flag
which is introduced in my kernel patch titled:
Hi Günter,
On 01/08/2013 04:48 PM, Günter Gersdorf wrote:
> Am 06.01.2013 19:28, schrieb Goffredo Baroncelli:
>>
>> You can pull the change from:
>> http://cassiopea.homelinux.net/git/util-linux.git
>> from the branch
>> btrfs-wipefs
>>
> After applying this patch, findfs and blkid didn't
On Jan 8, 2013, at 1:09 PM, Goffredo Baroncelli wrote:
> Hi Karel,
>
> On 01/08/2013 07:01 PM, Karel Zak wrote:
>> On Sun, Jan 06, 2013 at 07:28:55PM +0100, Goffredo Baroncelli wrote:
>>> If the first superblock is valid except that the "magic field" is zeroed,
>>> btrfs skips the check of the
Hi,
I believe there are two more cases, where we can safely avoid shipping
disknr=0 extent. These are cases, in which the file grows between the
two snapshots, and some of the new extents are no-data extents. So the
whole patch becomes:
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 5445454
Hi Karel,
On 01/08/2013 07:01 PM, Karel Zak wrote:
> On Sun, Jan 06, 2013 at 07:28:55PM +0100, Goffredo Baroncelli wrote:
>> If the first superblock is valid except that the "magic field" is zeroed,
>> btrfs skips the check of the other superblocks.
>> If the first superblock is fully invalid, btr
> This is for detecting extent map leak.
Hmm, I guess it's cool to get the allocation-specific decoding which you
don't get from the generic kernel leak tracking?
> +static LIST_HEAD(emaps);
> + while (!list_empty(&emaps)) {
> + em = list_entry(emaps.next, struct extent_map, leak
> Looks good (maybe IS_ERR_OR_NULL would be more future-proof, but *shrug*)
Yeah. I don't feel strongly about it. I'm happy to do that, and dance
around the tree pulling out redundant 'em = NULL' bits that wouldn't be
needed, if anyone feels strongly about it.
- z
(*shrug*)
--
To unsubscribe fr
On 1/8/13 1:37 PM, Zach Brown wrote:
> btrfs_cont_expand() tries to free an IS_ERR em as it gets an error from
> btrfs_get_extent() and breaks out of its loop.
>
> An instance of -EEXIST was reported in the wild:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=874407
>
> I have no idea if that
btrfs_cont_expand() tries to free an IS_ERR em as it gets an error from
btrfs_get_extent() and breaks out of its loop.
An instance of -EEXIST was reported in the wild:
https://bugzilla.redhat.com/show_bug.cgi?id=874407
I have no idea if that -EEXIST is surprising, or not. Regardless, this
err
On Tue, Jan 08, 2013 at 01:25:41PM -0500, Josef Bacik wrote:
> On Tue, Jan 08, 2013 at 09:49:58AM -0700, Marc MERLIN wrote:
> > Unfortunately my laptop deadlocks from time to time, and too often
> > it triggers this bug in btrfs which is quite hard to recover from.
> >
>
> You are getting bad tre
On Tue, Jan 08, 2013 at 09:49:58AM -0700, Marc MERLIN wrote:
> Unfortunately my laptop deadlocks from time to time, and too often
> it triggers this bug in btrfs which is quite hard to recover from.
>
You are getting bad tree blocks which really isn't the tree logs fault. Can you
scrub your file
See bottom, my filesystem mounts, but apparently it's still corrupted as per
btrfs-image output
On Tue, Jan 08, 2013 at 05:10:12PM +, Hugo Mills wrote:
> > Question #1:
> > I have hourly snapshots of my root filesystem, and I wasn't able to mount
> > any of them. I got the BUG at fs/btrfs/volu
On Sun, Jan 06, 2013 at 07:28:55PM +0100, Goffredo Baroncelli wrote:
> If the first superblock is valid except that the "magic field" is zeroed,
> btrfs skips the check of the other superblocks.
> If the first superblock is fully invalid, btrfs checks for the other
> superblock.
Hmm... why incons
Hello,
I tried to test LVM Raid1 robustness with following setup:
fallocate -l 128M file1
fallocate -l 128M file2
losetup /dev/loop0 file1
losetup /dev/loop1 file2
pvcreate /dev/loop{0,1}
vgcreate testvg /dev/loop{0,1}
lvcreate -L 100M --mirrorlog core -m 1 -n testlv testvg
So far so good. But
On Tue, Jan 08, 2013 at 09:30:54AM +0100, David Sterba wrote:
> On Tue, Jan 08, 2013 at 10:46:38AM +0800, Liu Bo wrote:
> > Hmm, not always here, lockend = inode->i_size - 1, so lockend % 2 == 1 may
> > not
> > be true.
>
> Yeah, that's the case that must be handled,
>
> > But this check can wor
On Mon, Jan 07, 2013 at 07:20:16PM +0100, Goffredo Baroncelli wrote:
> On 01/07/2013 05:33 PM, David Sterba wrote:
> > It can have as much as 4 superblock backup copies:
> >
> > Superblock offset 0 is 65536 (0x1, block=16/0x10)
> > Superblock offset 1 is 67108864 (0x400, block=16384/0x4000
On Tue, Jan 08, 2013 at 08:49:58AM -0800, Marc MERLIN wrote:
> Unfortunately my laptop deadlocks from time to time, and too often
> it triggers this bug in btrfs which is quite hard to recover from.
>
> The bigger problem is that all the user sees (if anything) is seemingly
> unrelated info, name
Unfortunately my laptop deadlocks from time to time, and too often
it triggers this bug in btrfs which is quite hard to recover from.
The bigger problem is that all the user sees (if anything) is seemingly
unrelated info, namely, "RIP: btrfs_num_copies+0x42/0x0b" or somesuch
http://marc.merlins.o
On Sun, Jan 06, 2013 at 07:28:55PM +0100, Goffredo Baroncelli wrote:
> +const struct blkid_idinfo btrfs_idinfo1 =
> +{
> + .name = "btrfs [bak #1]",
> + .usage = BLKID_USAGE_FILESYSTEM,
> + .probefunc = probe_btrfs,
> + .minsz = 64 * 1024 * 1024 + 4
Hi Chen, Alexander, Jan,
how about the following patch: it works for disknr==0 extents (to
handle PREALLOC extents correctly, we need to add a new command, which
will break existing btrfs-progs, because they are updated slower than
the kernel side).
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
i
Am 06.01.2013 19:28, schrieb Goffredo Baroncelli:
You can pull the change from:
http://cassiopea.homelinux.net/git/util-linux.git
from the branch
btrfs-wipefs
After applying this patch, findfs and blkid didn't find filesystems
smaller than 256GB, probably because there is no th
Running xfstests 83 in a loop would sometimes fail the fsck. This happens
because if we invalidate a page that already has an ordered extent setup for
it we will complete the ordered extent ourselves, assuming that the truncate
will clean everything up. The problem with this is there is plenty of
During fsync, we put the changed parts(i.e. extent map) into the log tree,
and we ship these parts from a list of modified_extents to a local list
to process, of course, we must increment the refs of the extent maps to
avoid it from getting evicted from cache.
The problem is
we don't hold the tree
This is for detecting extent map leak.
Signed-off-by: Liu Bo
---
fs/btrfs/extent_map.c | 31 +++
fs/btrfs/extent_map.h |1 +
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
index f169d6b..c025a7a 1006
On Mon, Dec 24, 2012 at 02:57:19AM -0700, Miao Xie wrote:
> We may try to flush some dirty pages when there is no enough space to reserve.
> But it is possible that this operation fails, in order to get enough space to
> reserve successfully, we will sync all the delalloc file. This operation is
>
On Tue, Jan 08, 2013 at 10:46:38AM +0800, Liu Bo wrote:
> On Mon, Jan 07, 2013 at 05:20:50PM +0100, David Sterba wrote:
> > On Mon, Jan 07, 2013 at 11:53:08AM +0800, Liu Bo wrote:
> > Fix looks ok. I think this should be caught at runtime as well, the
> > number of ways how the lock start and end a
39 matches
Mail list logo
