We used the wrong ioctl macro for the getflags ioctl before.
As we don't have the set/getflags ioctls in the user space ioctl.h
at the moment, it's safe to fix it now.
Reviewed-by: David Sterba dste...@suse.cz
Signed-off-by: Alexander Block abloc...@googlemail.com
---
fs/btrfs/ioctl.h |2 +-
This patch introduces uuids for subvolumes. Each
subvolume has it's own uuid. In case it was snapshotted,
it also contains parent_uuid. In case it was received,
it also contains received_uuid.
It also introduces subvolume ctime/otime/stime/rtime. The
first two are comparable to the times found in
Make iref_to_path non static (needed in send) and rename
it to btrfs_iref_to_path
Signed-off-by: Alexander Block abloc...@googlemail.com
---
fs/btrfs/backref.c | 10 +-
fs/btrfs/backref.h |4
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/backref.c
This function is used to find the differences between
two trees. The tree compare skips whole subtrees if it
detects shared tree blocks and thus is pretty fast.
Signed-off-by: Alexander Block abloc...@googlemail.com
---
fs/btrfs/ctree.c | 425
Hello all,
This is the user space side of btrfs send/receive.
You can apply them manually or use my git repo:
git://github.com/ablock84/btrfs-progs.git (branch send)
The branch is based on Hugo's integration-20120605 branch. I had to add a
temporary
commit to fix a bug introduced in one of
Update ctree.h and ioctl.h for the new uuid+times for subvolumes.
Signed-off-by: Alexander Block abloc...@googlemail.com
---
ctree.h | 40 -
ioctl.h | 12 +
print-tree.c | 79 +-
3 files
Add btrfs_ioctl_send_args and BTRFS_IOC_SEND to ioctl.h
Signed-off-by: Alexander Block abloc...@googlemail.com
---
ioctl.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/ioctl.h b/ioctl.h
index 77503e6..d35710c 100644
--- a/ioctl.h
+++ b/ioctl.h
@@ -282,6 +282,15 @@ struct
On Wed, Jul 04, 2012 at 07:40:05AM +0700, Fajar A. Nugraha wrote:
Are there any known btrfs regression in 3.4? I'm using 3.4.0-3-generic
from a ppa, but a normal mount - umount cycle seems MUCH longer
compared to how it was on 3.2, and iostat shows the disk is
read-IOPS-bound
Is it just
Hi,
On Tue, Jul 03, 2012 at 10:05:55PM -0700, Marc MERLIN wrote:
Since I heard absolutely nothing on my last but and corruption report, I'm
not sure if they are useful or wanted (please let me know).
They are, both useful and wanted, thanks.
The last thing I've seen with 3.4.4 is this:
Hi Martin,
On 02.07.2012 17:41, Jan Schmidt wrote:
I'm recently seeing such buffer leaks as well. It's always about tree blocks,
and it's always just two or three refs left for a buffer. I can somehow
reproduce it and will be looking into it probably tomorrow. (May still be
unrelated, of
If a block group is ro, do not count its entries in when we dump space info.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/free-space-cache.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index
We can set a block group readonly when we relocate the block group.
If the block group covers the disk offset where our free space
cache inode is going to write, it will force the free space cache
inode into cow_file_range(), which is not allowed due to free space
cache design.
Signed-off-by:
During disk balance, we prealloc new file extent for file data relocation,
but we may fail in 'no available space' case, and only under this case can
the error be reported to userspace, so we do not need to abort transaction
here.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
Block group has ro attributes, make dump_space_info show it.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/extent-tree.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index bbe79ab..f29859b 100644
---
When calling btrfs_next_old_leaf, we were leaking an extent buffer in the
rare case of using the deadlock avoidance code needed for the tree mod log.
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
---
fs/btrfs/ctree.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Chris: you
On Wed, Jul 04, 2012 at 03:53:05PM +0200, David Sterba wrote:
Hi,
On Tue, Jul 03, 2012 at 10:05:55PM -0700, Marc MERLIN wrote:
Since I heard absolutely nothing on my last but and corruption report, I'm
not sure if they are useful or wanted (please let me know).
They are, both useful and
On Wed, Jul 04, 2012 at 07:39:28AM -0600, Alexander Block wrote:
Hello all,
This is the user space side of btrfs send/receive.
You can apply them manually or use my git repo:
git://github.com/ablock84/btrfs-progs.git (branch send)
The branch is based on Hugo's integration-20120605
On Wed, Jul 04, 2012 at 01:58:31PM +0800, Liu Bo wrote:
The dmesg log, sysrq log and stack dump info can usually be very helpful.
From your report, we can see the csum error and hang on log,
'no csum' is not that bad while hanging-on is serious and dangerous.
so can you please get any
Hi,
this is not really a bug in btrfs but to spread the info I will just
drop this short message:
My System (VirtualBox VM, 3 virtual HDDs with 10G, 5G and 3G) is today
installed Ubuntu 12.04 LTS 64bit with Kernel 3.2.0-26 generic, a
/dev/sda hdd containing /boot with ext4 and / with btrfs.
On Fri, Jun 29, 2012 at 06:00:38PM +0800, Liu Bo wrote:
We want 'btrfs subvolume list' to act as 'ls', which means that
we can not only list out all the subvolumes we have, but also list
each single one.
So this patch add 's' option to show a single one:
$ ./btrfs sub list /mnt/btrfs/
ID
On Wed, Jul 4, 2012 at 8:42 PM, David Sterba d...@jikos.cz wrote:
On Wed, Jul 04, 2012 at 07:40:05AM +0700, Fajar A. Nugraha wrote:
Are there any known btrfs regression in 3.4? I'm using 3.4.0-3-generic
from a ppa, but a normal mount - umount cycle seems MUCH longer
compared to how it was on
On Sun, Jul 01, 2012 at 06:16:55PM +0800, Jeff Liu wrote:
On 07/01/2012 05:49 PM, Zhi Yong Wu wrote:
On Sun, Jul 1, 2012 at 5:41 PM, Mike Fleetwood
No, i also did as this, but didn't find out who will invoke this
function. From above output, we only saw that it invokes itself one
time.
On Wed, Jul 04, 2012 at 01:26:46PM +0200, Jan Schmidt wrote:
On 04.07.2012 02:17, Sami Liedes wrote:
On Wed, Jul 04, 2012 at 01:47:56AM +0300, Sami Liedes wrote:
I've seen this before: An overly long Modules linked in: line causes
a large gap in netconsole output.
I managed to capture
On 04.07.2012 18:03, Sami Liedes wrote:
Here you go.
Sami
[...]
[ 200.980496] btrfs: invalid parameters for read_extent_buffer: start
(32771) eb-len (32768). eb start is 2243489562624, level 26, generation
3144240307695375391, nritems 620178657. len param 17. debug
Hi Alex,
+ spin_lock(left_root-root_times_lock);
+ ctransid = btrfs_root_ctransid(left_root-root_item);
+ spin_unlock(left_root-root_times_lock);
+ if (ctransid != left_start_ctransid)
+
Hi Alex,
+static int tree_compare_item(struct btrfs_root *left_root,
+struct btrfs_path *left_path,
+struct btrfs_path *right_path,
+char *tmp_buf)
+{
+ int cmp;
+ int len1, len2;
+
On Wed, Jul 4, 2012 at 8:27 PM, Alex Lyakas
alex.bolshoy.bt...@gmail.com wrote:
Hi Alex,
+ spin_lock(left_root-root_times_lock);
+ ctransid =
btrfs_root_ctransid(left_root-root_item);
+ spin_unlock(left_root-root_times_lock);
On Wed, Jul 4, 2012 at 9:13 PM, Alex Lyakas
alex.bolshoy.bt...@gmail.com wrote:
Hi Alex,
+static int tree_compare_item(struct btrfs_root *left_root,
+struct btrfs_path *left_path,
+struct btrfs_path *right_path,
+
On Wed, Jul 04, 2012 at 06:38:00PM +0200, Jan Schmidt wrote:
[ 200.980496] btrfs: invalid parameters for read_extent_buffer: start
(32771) eb-len (32768). eb start is 2243489562624, level 26, generation
3144240307695375391, nritems 620178657. len param 17. debug
On Wed, Jul 04, 2012 at 10:18:34PM +0200, Alexander Block wrote:
It might be worth to note in the comment, that tmp_buff should be
large enough to hold the item from the left tree. Can it happen that
the right tree has a different leafsize?
This function is only to be used for for the
On Wed, Jul 04, 2012 at 10:46:21PM +0700, Fajar A. Nugraha wrote:
Is it just mount/umount without any other activity?
Yes
Is the fs
fragmented
Not sure how to check that quickly
(or aged),
Over 1 year, so yes
almost full,
df says 83% used, so probably yes (depending on how you
On 2012/7/4 19:04, Alexander Block wrote:
On Wed, Jul 4, 2012 at 9:56 AM, Li Zefan lize...@huawei.com wrote:
On 2012/7/4 15:18, chandan r wrote:
This patch adds a new member to the 'struct btrfs_inode' structure to hold
the file creation time.
Well, how do users use this file creation
On Thu, Jul 5, 2012 at 3:07 AM, Li Zefan lize...@huawei.com wrote:
On 2012/7/4 19:04, Alexander Block wrote:
On Wed, Jul 4, 2012 at 9:56 AM, Li Zefan lize...@huawei.com wrote:
On 2012/7/4 15:18, chandan r wrote:
This patch adds a new member to the 'struct btrfs_inode' structure to hold
the
On 4 July 2012 13:19, Liu Bo liubo2...@cn.fujitsu.com wrote:
On 07/04/2012 11:37 AM, Daniel J Blueman wrote:
Hi everyone,
I've got a nice set of fixes from Josef, Jan, Ilya and others in my
for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus
This patch adds a new member to the 'struct btrfs_inode' structure to hold
the file creation time.
Signed-off-by: chandan chandanrm...@gmail.com
---
fs/btrfs/btrfs_inode.h | 3 +++
fs/btrfs/ctree.h | 8
fs/btrfs/delayed-inode.c | 10 +-
fs/btrfs/inode.c | 25
On 2012/7/4 15:18, chandan r wrote:
This patch adds a new member to the 'struct btrfs_inode' structure to hold
the file creation time.
Well, how do users use this file creation time? There's no syscall and there's
no ioctl that exports this information. That xstat syscall hasn't been
On Wed, Jul 4, 2012 at 9:56 AM, Li Zefan lize...@huawei.com wrote:
On 2012/7/4 15:18, chandan r wrote:
This patch adds a new member to the 'struct btrfs_inode' structure to hold
the file creation time.
Well, how do users use this file creation time? There's no syscall and there's
no ioctl
On 04.07.2012 02:17, Sami Liedes wrote:
On Wed, Jul 04, 2012 at 01:47:56AM +0300, Sami Liedes wrote:
I've seen this before: An overly long Modules linked in: line causes
a large gap in netconsole output.
I managed to capture the entire output using netconsole by modifying
the kernel to not
Hello all,
This patchset introduces the btrfs send ioctl, which creates a stream
of instructions that can later be replayed to reconstruct the sent
subvolumes/snapshots. Patches for btrfs-progs will follow in a separate
patchset.
Some of you may remember the previous discussions on send/receive.
39 matches
Mail list logo
