subvolumes: default and IDs
Hey! I recently starting playing with btrfs and subvolume, but it has left me puzzled: Distribution is Archlinux, Kernel is 3.4.6. root@horus /mnt # mkfs.btrfs -L test /dev/sdb1 WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using fs created label test on /dev/sdb1 nodesize 4096 leafsize 4096 sectorsize 4096 size 2.73TB Btrfs Btrfs v0.19 root@horus /mnt # mount /dev/sdb1 test root@horus /mnt # cd test root@horus /mnt/test # btrfs subvolume create sv1 Create subvolume './sv1' root@horus /mnt/test # btrfs subvolume create sv2 Create subvolume './sv2' root@horus /mnt/test # touch sv1/sv1.file root@horus /mnt/test # touch sv2/sv2.file root@horus /mnt/test # btrfs subvolume get-default . ID 256 top level 5 path sv1 ID 259 top level 5 path sv2 What is the default subvolume now? How can I tell? root@horus /mnt/test # btrfs subvolume set-default 259 . root@horus /mnt/test # btrfs subvolume get-default . ID 256 top level 5 path sv1 ID 259 top level 5 path sv2 Seems to have changed nothing? root@horus /mnt/test # cd .. root@horus /mnt # umount test mount /dev/sdb1 test root@horus /mnt # ls test sv2.file Ah, sv2 seems to be default, like I had set it. root@horus /mnt # btrfs subvolume set-default 5 test root@horus /mnt # umount test /mnt # mount /dev/sdb1 test root@horus /mnt # ls test sv1/ sv2/ Ok, 5 seems to be the root subvolume id. Is it always like that? I remembered to have read somewhere it was 0 ? (which makes a kind of more sense for me) root@horus /mnt # btrfs subvolume set-default 256 test root@horus /mnt # umount test mount /dev/sdb1 test root@horus /mnt # ls test sv1.file Fine! But: root@horus /mnt # btrfs subvolume set-default 0 test root@horus /mnt # umount test mount /dev/sdb1 test root@horus /mnt # ls test sv1.file set-default 0 seems to do nothing but does not produce an error either. What about subvolume 0? Still I can do: root@horus /mnt # umount test root@horus /mnt # mount -o subvolid=0 /dev/sdb1 test root@horus /mnt # ls test sv1/ sv2/ Ok, here 0 as subvolid works. What about subvolid=5? root@horus /mnt # umount test root@horus /mnt # mount -o subvolid=5 /dev/sdb1 test root@horus /mnt # ls test sv1/ sv2/ Works too. Sorry for the lengthy posting, but writing this posting has puzzled me even more I was yesterday. I hope someone could shed some light on it. Thanks! Florian -- 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-info.html
[patch] Btrfs: fix some endian bugs handling the root times
trans-transid is cpu endian but we want to store the data as little endian. item-ctime.nsec is only 32 bits, not 64. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- Applies to linux-next. diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 43f0012..a1fbca0 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -424,7 +424,7 @@ static noinline int create_subvol(struct btrfs_root *root, uuid_le_gen(new_uuid); memcpy(root_item.uuid, new_uuid.b, BTRFS_UUID_SIZE); root_item.otime.sec = cpu_to_le64(cur_time.tv_sec); - root_item.otime.nsec = cpu_to_le64(cur_time.tv_nsec); + root_item.otime.nsec = cpu_to_le32(cur_time.tv_nsec); root_item.ctime = root_item.otime; btrfs_set_root_ctransid(root_item, trans-transid); btrfs_set_root_otransid(root_item, trans-transid); diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index 7ac7cdc..7208ada 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -1061,7 +1061,7 @@ static noinline int create_pending_snapshot(struct btrfs_trans_handle *trans, memcpy(new_root_item-parent_uuid, root-root_item.uuid, BTRFS_UUID_SIZE); new_root_item-otime.sec = cpu_to_le64(cur_time.tv_sec); - new_root_item-otime.nsec = cpu_to_le64(cur_time.tv_nsec); + new_root_item-otime.nsec = cpu_to_le32(cur_time.tv_nsec); btrfs_set_root_otransid(new_root_item, trans-transid); memset(new_root_item-stime, 0, sizeof(new_root_item-stime)); memset(new_root_item-rtime, 0, sizeof(new_root_item-rtime)); diff --git a/fs/btrfs/root-tree.c b/fs/btrfs/root-tree.c index 6bb465c..10d8e4d 100644 --- a/fs/btrfs/root-tree.c +++ b/fs/btrfs/root-tree.c @@ -544,8 +544,8 @@ void btrfs_update_root_times(struct btrfs_trans_handle *trans, struct timespec ct = CURRENT_TIME; spin_lock(root-root_times_lock); - item-ctransid = trans-transid; + item-ctransid = cpu_to_le64(trans-transid); item-ctime.sec = cpu_to_le64(ct.tv_sec); - item-ctime.nsec = cpu_to_le64(ct.tv_nsec); + item-ctime.nsec = cpu_to_le32(ct.tv_nsec); spin_unlock(root-root_times_lock); } -- 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-info.html
[patch 1/2] Btrfs: checking for NULL instead of IS_ERR
add_qgroup_rb() never returns NULL, only error pointers.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Applies to linux-next.
diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
index bc424ae..b650155 100644
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -1364,8 +1364,10 @@ int btrfs_qgroup_inherit(struct btrfs_trans_handle
*trans,
spin_lock(fs_info-qgroup_lock);
dstgroup = add_qgroup_rb(fs_info, objectid);
- if (!dstgroup)
+ if (IS_ERR(dstgroup)) {
+ ret = PTR_ERR(dstgroup);
goto unlock;
+ }
if (srcid) {
srcgroup = find_qgroup_rb(fs_info, srcid);
--
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-info.html
[patch 2/2] Btrfs: fix some error codes in btrfs_qgroup_inherit()
These are returning zero when it should be returning a negative error
code.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Applies to linux-next.
diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
index b650155..38b42e7 100644
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -1371,8 +1371,10 @@ int btrfs_qgroup_inherit(struct btrfs_trans_handle
*trans,
if (srcid) {
srcgroup = find_qgroup_rb(fs_info, srcid);
- if (!srcgroup)
+ if (!srcgroup) {
+ ret = -EINVAL;
goto unlock;
+ }
dstgroup-rfer = srcgroup-rfer - level_size;
dstgroup-rfer_cmpr = srcgroup-rfer_cmpr - level_size;
srcgroup-excl = level_size;
@@ -1381,8 +1383,10 @@ int btrfs_qgroup_inherit(struct btrfs_trans_handle
*trans,
qgroup_dirty(fs_info, srcgroup);
}
- if (!inherit)
+ if (!inherit) {
+ ret = -EINVAL;
goto unlock;
+ }
i_qgroups = (u64 *)(inherit + 1);
for (i = 0; i inherit-num_qgroups; ++i) {
--
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-info.html
Re: severe hardlink bug
Am 29.07.2012 21:13, schrieb C Anthony Risinger: On Sun, Jul 29, 2012 at 2:02 PM, Konstantin Dmitriev ksee.zelga...@gmail.com wrote: Dipl.-Ing. Michael Niederle mniederle at gmx.at writes: I reinstalled over 700 packages - plt-scheme beeing the only one failing due to the btrfs link restriction. I have hit the same issue - tried to run BackupPC with a pool on btrfs filesystem. After some time the error of too many links (31) appeared to me. Now I'm forced to migrate to some other filesystem... btrfs only fails when you have hundreds of hardlinks to the same file in the *same* directory ... certainly not a standard use case. Actually, hundreds of hardlinks is certainly over optimistic. In my testing 15 links in the same directory were enough to get the Too many links error. It depends on the length of the file name of the hardlinks. Best regards Arnd -- 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-info.html
[PATCH v2] xfstests: add btrfs snapshot function test
From: Zhou Bo zhoub-f...@cn.fujitsu.com
This patch adds btrfs snapshot function test to xfstests
Signed-off-by: Zhou Bo zhoub-f...@cn.fujitsu.com
---
v2: address comments from David Sterba
285 | 387 +++
285.out |2 +
group |1 +
3 files changed, 390 insertions(+), 0 deletions(-)
create mode 100755 285
create mode 100644 285.out
diff --git a/285 b/285
new file mode 100755
index 000..2842384
--- /dev/null
+++ b/285
@@ -0,0 +1,387 @@
+#! /bin/bash
+# FS QA Test No. 285
+#
+# Snapshot QA test with different mount options and stress:
+# mount options: default, ro, nodatacow
+# stress: balance
+#
+#---
+# Copyright (c) 2012 Fujitsu. All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#
+#---
+#
+# creator
+owner=zhoub-f...@cn.fujitsu.com
+
+n=0
+seq=`basename $0`
+echo QA output created by $seq
+
+here=`pwd`
+tmp=/tmp/$$
+status=0 # success is the default!
+
+_cleanup()
+{
+rm -f $tmp.*
+}
+
+trap _cleanup ; exit \$status 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+# real QA test starts here
+_supported_fs btrfs
+_supported_os Linux
+_require_scratch
+# file size is 2G
+_scratch_mkfs_sized `expr 2 \* 1024 \* 1024 \* 1024` /dev/null 21
+_scratch_mount
+
+_prepare_snapshot()
+{
+ _scratch_remount /dev/null
+ btrfs subvolume snapshot $SCRATCH_MNT $SCRATCH_MNT/basesnapshot
/dev/null 2$here/$seq.full
+ btrfs subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/readonlysnapshot
/dev/null 2$here/$seq.full
+ _scratch_unmount /dev/null 2$here/$seq.full
+ VALID_SUBVOLUME=basesnapshot
+ VALID_RO_SUBVOLUME=readonlysnapshot
+ SNAPSHOTSTR=snapshot
+ FILE1=file1-
+ FILE2=file2-
+ MVFILE2=newfile2-
+ DIR1=dir1-
+ DIR2=dir2-
+ MVDIR2=newdir2-
+ MVSNAPSHOT=mvsnapshot-
+ SRCSUBVOL=srcsubvol-
+}
+
+_parse_options()
+{
+ SOURCE_TARGET=$1
+ case $SOURCE_TARGET in
+ 1)
+ SOURCE_SUBVOLUME=$VALID_SUBVOLUME
+ ;;
+ esac
+ SOURCE_RO=$2
+ case $SOURCE_RO in
+ 1)
+ SOURCE_SUBVOLUME=$VALID_RO_SUBVOLUME
+ ;;
+ esac
+ DESTINATION_TARGET=$3
+ case $DESTINATION_TARGET in
+ 1)
+ DESTINATION_SUBVOLUME=$SNAPSHOTSTR$n
+ ;;
+ esac
+ DESTINATION_RO=$4
+ case $DESTINATION_RO in
+ 1)
+ SNAPSHOT_OPT_STR=-r
+ ;;
+ 2)
+ SNAPSHOT_OPT_STR=
+ ;;
+ esac
+ MOUNT_OPT=$5
+ case $MOUNT_OPT in
+ 1)
+ MOUNT_OPT_STR=
+ ;;
+ 2)
+ MOUNT_OPT_STR=-r
+ ;;
+ 3)
+ MOUNT_OPT_STR=-o nodatacow
+ ;;
+ esac
+ FILE_OPERATION_OPT=$6
+ SNAPSHOT_ACTION_OPT=$7
+ TEST_DIR1=$DIR1$n
+ TEST_DIR2=$DIR2$n
+ TEST_MVDIR2=$MVDIR2$n
+ TEST_FILE1=$FILE1$n
+ TEST_FILE2=$FILE2$n
+ TEST_MVFILE2=$MVFILE2$n
+ TEST_MVSNAPSHOT=$MVSNAPSHOT$n
+ SRC_SUBVOLUME=$SRCSUBVOL$n
+ n=$[n+1]
+}
+
+_create_file()
+{
+ mkdir $SRC_SUBVOLUME/$TEST_DIR1 $SRC_SUBVOLUME/$TEST_DIR2 /dev/null
+ touch $SRC_SUBVOLUME/$TEST_FILE1 $SRC_SUBVOLUME/$TEST_FILE2 /dev/null
+}
+
+_do_balance_operation()
+{
+ btrfs filesystem balance start $SCRATCH_MNT /dev/null 21
+}
+
+_do_file_operation()
+{
+ rm -rf $SRC_SUBVOLUME/$TEST_DIR1 $SRC_SUBVOLUME/$TEST_FILE1 /dev/null
+ mv $SRC_SUBVOLUME/$TEST_DIR2 $SRC_SUBVOLUME/$TEST_MVDIR2 /dev/null
+ mv $SRC_SUBVOLUME/$TEST_FILE2 $SRC_SUBVOLUME/$TEST_MVFILE2 /dev/null
+}
+
+_do_snapshot_action()
+{
+ if [ $SNAPSHOT_ACTION_OPT == 2 ];then
+ btrfs subvolume delete $DESTINATION_SUBVOLUME /dev/null
2$here/$seq.full
+ fi
+ if [ $SNAPSHOT_ACTION_OPT == 3 ];then
+ mv $DESTINATION_SUBVOLUME $TEST_MVSNAPSHOT /dev/null
2$here/$seq.full
+
Re: severe hardlink bug
On Mon, Jul 30, 2012 at 4:36 AM, Arnd Hannemann a...@arndnet.de wrote: Am 29.07.2012 21:13, schrieb C Anthony Risinger: On Sun, Jul 29, 2012 at 2:02 PM, Konstantin Dmitriev ksee.zelga...@gmail.com wrote: Dipl.-Ing. Michael Niederle mniederle at gmx.at writes: I reinstalled over 700 packages - plt-scheme beeing the only one failing due to the btrfs link restriction. I have hit the same issue - tried to run BackupPC with a pool on btrfs filesystem. After some time the error of too many links (31) appeared to me. Now I'm forced to migrate to some other filesystem... btrfs only fails when you have hundreds of hardlinks to the same file in the *same* directory ... certainly not a standard use case. Actually, hundreds of hardlinks is certainly over optimistic. In my testing 15 links in the same directory were enough to get the Too many links error. It depends on the length of the file name of the hardlinks. Yes, per the linked patch it states 4k as the limit ... I thought I recalled a limit of 256 but it seems I may have been mistaken. The purpose of my initial response was to suggest an alternative strategy -- one complementing btrfs's strengths -- a simple rsync + snapshot is much more effective than BackupPC IMO ... but then again, I'm bias, because I generally think BackupPC is junk. -- C Anthony -- 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-info.html
Re: [PATCH 2/2] Btrfs: fix the snapshot that should not exist
On fri, 27 Jul 2012 16:52:21 +0900, Hidetoshi Seto wrote:
# ll /mnt/1/snap0/1
total 0
[None]
# cd /mnt/1/snap0/1/snap0
[Enter a unexisted directory successfully...]
I confirmed that mkdir snap0 failed with File exists and
that rmdir can remove the directory snap0. So it is a kind of
invisible rather than unexisted.
I think it is not like the typically invisible directories on linux, and in the
users'
view, this directory should not exist, in other words, it is a unexisted
directory to
the users, so I use unexisted.
(snip)
@@ -1062,17 +1068,33 @@ static noinline int create_pending_snapshot(struct
btrfs_trans_handle *trans,
ret = btrfs_reloc_post_snapshot(trans, pending);
if (ret)
goto abort_trans;
+
+ret = btrfs_insert_dir_item(trans, parent_root,
+dentry-d_name.name, dentry-d_name.len,
+parent_inode, key,
+BTRFS_FT_DIR, index);
+/* We have check the name at the beginning, so it is impossible. */
+BUG_ON(ret == -EEXIST);
+if (ret)
+goto abort_trans;
+
+btrfs_i_size_write(parent_inode, parent_inode-i_size +
+ dentry-d_name.len * 2);
+ret = btrfs_update_inode(trans, parent_root, parent_inode);
+if (ret)
+goto abort_trans;
fail:
dput(parent);
trans-block_rsv = rsv;
no_free_objectid:
kfree(new_root_item);
root_item_alloc_fail:
+btrfs_free_path(path);
+path_alloc_fail:
btrfs_block_rsv_release(root, pending-block_rsv, (u64)-1);
return ret;
abort_trans:
-dput(parent);
I think you can remove this line in your 1/2 patch.
Yes. will be modified in the next version of the patches.
btrfs_abort_transaction(trans, root, ret);
goto fail;
}
@@ -1386,13 +1408,13 @@ int btrfs_commit_transaction(struct
btrfs_trans_handle *trans,
*/
mutex_lock(root-fs_info-reloc_mutex);
-ret = btrfs_run_delayed_items(trans, root);
+ret = create_pending_snapshots(trans, root-fs_info);
if (ret) {
mutex_unlock(root-fs_info-reloc_mutex);
goto cleanup_transaction;
}
-ret = create_pending_snapshots(trans, root-fs_info);
+ret = btrfs_run_delayed_items(trans, root);
if (ret) {
mutex_unlock(root-fs_info-reloc_mutex);
goto cleanup_transaction;
It would be nice to have a patch description to tell why you
have to change the order here.
OK, I will add comment in the next version of the patches.
Thanks for your review.
Miao
--
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-info.html
Re: severe hardlink bug
Hallo, Arnd, Du meintest am 30.07.12: btrfs only fails when you have hundreds of hardlinks to the same file in the *same* directory ... certainly not a standard use case. Actually, hundreds of hardlinks is certainly over optimistic. In my testing 15 links in the same directory were enough to get the Too many links error. It depends on the length of the file name of the hardlinks. And then I may get problems with my favourite backup program rsnapshot; it uses hard links, and my backups often have more than 20 hard links to 1 file. Sometimes about 80 characters long. Viele Gruesse! Helmut -- 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-info.html
Re: [PATCH 2/2] Btrfs: fix the snapshot that should not exist
On fri, 27 Jul 2012 14:29:57 +0200, David Sterba wrote:
On Fri, Jul 27, 2012 at 04:52:21PM +0900, Hidetoshi Seto wrote:
(2012/07/26 15:57), Miao Xie wrote:
btrfs_abort_transaction(trans, root, ret);
goto fail;
}
@@ -1386,13 +1408,13 @@ int btrfs_commit_transaction(struct
btrfs_trans_handle *trans,
*/
mutex_lock(root-fs_info-reloc_mutex);
- ret = btrfs_run_delayed_items(trans, root);
+ ret = create_pending_snapshots(trans, root-fs_info);
if (ret) {
mutex_unlock(root-fs_info-reloc_mutex);
goto cleanup_transaction;
}
- ret = create_pending_snapshots(trans, root-fs_info);
+ ret = btrfs_run_delayed_items(trans, root);
if (ret) {
mutex_unlock(root-fs_info-reloc_mutex);
goto cleanup_transaction;
It would be nice to have a patch description to tell why you
have to change the order here.
Not only nice but necessary, as this order will cause corruption under
certain conditions. I'd like to hear the reason behind.
What you worried is the corruption of the snapshots, right?
It is impossible because we will flush all the delayed items before the
creation of the snapshot(in create_pending_snapshot()). and we also will
force the tree to COW if we want to change it after it is snapshoted.
These two method will make sure the snapshots is healthy.
Thanks
Miao
--
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-info.html
Re: subvolumes: default and IDs
On Mon, 2012-07-30 at 09:56 +0200, Florian Lindner wrote: Hey! I recently starting playing with btrfs and subvolume, but it has left me puzzled: root@horus /mnt/test # btrfs subvolume get-default . ID 256 top level 5 path sv1 ID 259 top level 5 path sv2 What is the default subvolume now? How can I tell? It looks like there's currently a bug in btrfs-progs - the 'get-default' command is actually doing a 'list' instead of printing the default. With any luck it's just a little error in the command-line parsing and should be easy to fix... root@horus /mnt # btrfs subvolume set-default 5 test root@horus /mnt # umount test /mnt # mount /dev/sdb1 test root@horus /mnt # ls test sv1/ sv2/ Ok, 5 seems to be the root subvolume id. Is it always like that? I remembered to have read somewhere it was 0 ? (which makes a kind of more sense for me) The internal ID of the root subvolume is 5, yes. I don't know whether this is a current implementation detail and subject to change, or if it will permanently stay that way. I *think* it's part of the disk format, and it permanent. In either case, the subvol id '0' is treated as an alias for 'the original root subvolume', and the two can be used interchangeably in the mount command. I always find '0' just a bit easier to remember :) root@horus /mnt # btrfs subvolume set-default 0 test root@horus /mnt # umount test mount /dev/sdb1 test root@horus /mnt # ls test sv1.file set-default 0 seems to do nothing but does not produce an error either. Looks like you've found another bug (or maybe just a missing feature); it would be nice if this command allows you to use '0' as an alias for the root subvolume. -- Calvin Walton calvin.wal...@kepstin.ca -- 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-info.html
Re: subvolumes: default and IDs
On 07/30/2012 03:56 PM, Florian Lindner wrote: Hey! I recently starting playing with btrfs and subvolume, but it has left me puzzled: Distribution is Archlinux, Kernel is 3.4.6. root@horus /mnt # mkfs.btrfs -L test /dev/sdb1 WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using fs created label test on /dev/sdb1 nodesize 4096 leafsize 4096 sectorsize 4096 size 2.73TB Btrfs Btrfs v0.19 root@horus /mnt # mount /dev/sdb1 test root@horus /mnt # cd test root@horus /mnt/test # btrfs subvolume create sv1 Create subvolume './sv1' root@horus /mnt/test # btrfs subvolume create sv2 Create subvolume './sv2' root@horus /mnt/test # touch sv1/sv1.file root@horus /mnt/test # touch sv2/sv2.file root@horus /mnt/test # btrfs subvolume get-default . ID 256 top level 5 path sv1 ID 259 top level 5 path sv2 What is the default subvolume now? How can I tell? root@horus /mnt/test # btrfs subvolume set-default 259 . root@horus /mnt/test # btrfs subvolume get-default . ID 256 top level 5 path sv1 ID 259 top level 5 path sv2 Seems to have changed nothing? root@horus /mnt/test # cd .. root@horus /mnt # umount test mount /dev/sdb1 test root@horus /mnt # ls test sv2.file Ah, sv2 seems to be default, like I had set it. root@horus /mnt # btrfs subvolume set-default 5 test root@horus /mnt # umount test /mnt # mount /dev/sdb1 test root@horus /mnt # ls test sv1/ sv2/ Ok, 5 seems to be the root subvolume id. Is it always like that? I remembered to have read somewhere it was 0 ? (which makes a kind of more sense for me) root@horus /mnt # btrfs subvolume set-default 256 test root@horus /mnt # umount test mount /dev/sdb1 test root@horus /mnt # ls test sv1.file Fine! But: root@horus /mnt # btrfs subvolume set-default 0 test root@horus /mnt # umount test mount /dev/sdb1 test root@horus /mnt # ls test sv1.file set-default 0 seems to do nothing but does not produce an error either. What about subvolume 0? Still I can do: root@horus /mnt # umount test root@horus /mnt # mount -o subvolid=0 /dev/sdb1 test root@horus /mnt # ls test sv1/ sv2/ Ok, here 0 as subvolid works. What about subvolid=5? root@horus /mnt # umount test root@horus /mnt # mount -o subvolid=5 /dev/sdb1 test root@horus /mnt # ls test sv1/ sv2/ Works too. Sorry for the lengthy posting, but writing this posting has puzzled me even more I was yesterday. I hope someone could shed some light on it. Hi Florian, Thanks for reporting these! They are old bugs that had been fixed recently in latest btrfs progs, you can checkout the latest btrfs-progs from git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git subvolid=0 will be translated to subvolid=5 since 5 indicates btrfs' fs tree (the root subvolume as you mentioned) thanks, liubo Thanks! Florian -- 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-info.html -- 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-info.html
Re: subvolumes: default and IDs
Le 30/07/2012 13:29, Calvin Walton a écrit : It looks like there's currently a bug in btrfs-progs - the 'get-default' command is actually doing a 'list' instead of printing the default. With any luck it's just a little error in the command-line parsing and should be easy to fix... I've fallen upon this one as well. That's typically the kind of bug that makes one wonder to what extent the software has ever been tested, and doubt it's anything close to production quality... :-/ -- Swâmi Petaramesh sw...@petaramesh.org http://petaramesh.org PGP 9076E32E -- 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-info.html
Re: [PATCH 0/1] Btrfs: Explicitly include vmalloc.h in send.c
On Sat, Jul 28, 2012 at 04:20:02PM -0600, Mitch Harder wrote: When compiling without SMP and generic x86_64, I encountered the following errors due to vmalloc.h not being implicitly included: CC fs/btrfs/send.o fs/btrfs/send.c: In function ‘fs_path_free’: fs/btrfs/send.c:185:4: error: implicit declaration of function ‘vfree’ fs/btrfs/send.c: In function ‘fs_path_ensure_buf’: fs/btrfs/send.c:215:4: error: implicit declaration of function ‘vmalloc’ fs/btrfs/send.c:215:12: warning: assignment makes pointer from integer without a cast fs/btrfs/send.c:225:12: warning: assignment makes pointer from integer without a cast fs/btrfs/send.c:233:13: warning: assignment makes pointer from integer without a cast fs/btrfs/send.c: In function ‘iterate_dir_item’: fs/btrfs/send.c:900:10: warning: assignment makes pointer from integer without a cast fs/btrfs/send.c:909:11: warning: assignment makes pointer from integer without a cast fs/btrfs/send.c: In function ‘btrfs_ioctl_send’: fs/btrfs/send.c:4462:17: warning: assignment makes pointer from integer without a cast fs/btrfs/send.c:4468:17: warning: assignment makes pointer from integer without a cast fs/btrfs/send.c:4474:2: error: implicit declaration of function ‘vzalloc’ fs/btrfs/send.c:4474:20: warning: assignment makes pointer from integer without a cast fs/btrfs/send.c:4482:21: warning: assignment makes pointer from integer without a cast make[2]: *** [fs/btrfs/send.o] Error 1 make[1]: *** [fs/btrfs] Error 2 If it makes sense, please feel free to include this minor change in with other send/receive fixes. Mitch Harder (1): Btrfs: Explicitly include vmalloc.h in send.c fs/btrfs/send.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Already fixed by the linux-next maintainer. Thanks, 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-info.html
Re: [PATCH 0/8] Set bi_rw when alloc bio before call bio_add_page.
On Mon, Jul 30, 2012 at 03:14:28PM +0800, majianpeng wrote: When exec bio_alloc, the bi_rw is zero.But after calling bio_add_page, What about submit_bio? That sets the bi_rw as well? it will use bi_rw. Fox example, in functiion __bio_add_page,it will call merge_bvec_fn(). function. The merge_bvec_fn of raid456 will use the bi_rw to judge the merge. if ((bvm-bi_rw 1) == WRITE) return biovec-bv_len; /* always allow writes to be mergeable */ So what does that mean? Without this patch what happens? Jianpeng Ma (8): Can you collapse all of this in just one patch? Evalue bio-bi_rw after calling bio_alloc() and before calling It is 'evaluate' bio_add_page(). Evalue bio-bi_rw after calling bio_alloc() and before calling bio_add_page(). Evalue bio-bi_rw after calling bio_alloc() and before calling bio_add_page(). Evalue bio-bi_rw after calling bio_alloc() and before calling bio_add_page(). Evalue bio-bi_rw after calling bio_alloc() and before calling bio_add_page(). Evalue bio-bi_rw after calling bio_alloc() and before calling bio_add_page(). Evalue bio-bi_rw after calling bio_alloc() and before calling bio_add_page(). Evalue bio-bi_rw after calling bio_alloc() and before calling bio_add_page(). block/blk-lib.c |1 + drivers/block/xen-blkback/blkback.c |1 + I am not really sure if that is correct. Does 'submit_bio' not do the job properly? fs/btrfs/check-integrity.c |1 + fs/direct-io.c |1 + fs/ext4/page-io.c |1 + fs/jfs/jfs_metapage.c |1 + fs/ocfs2/cluster/heartbeat.c|8 +--- fs/xfs/xfs_aops.c |2 ++ fs/xfs/xfs_buf.c|1 + 9 files changed, 14 insertions(+), 3 deletions(-) -- 1.7.9.5 -- 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-info.html
Re: btrfs send/receive: if new inode ino is less than its new directory ino, incorrect path is sent
Hi, I did not apply the patch but instead added a check for dir != tmp_dir only. The reason to not check for gen is that I have a rule in my mind: I only pass the generation number to functions where I want to know the *current* state. is_first_ref is for permanent state, the return value never changes while sending. I could however not reproduce the problem with test_1.sh, but it should fix it. I understand. I was not sure about dir_gen either. Since you call this function to check the permanent state in a particular root, it does not make sense to compare the generation. btrfs_test_2.sh The last test exposes an interesting issue: when a directory has a deleted reference recorded, this deleted reference is not added to the 'check_dirs' list. As a result, the upper directory (already orphanized) is not rmdir'd. You'll find a commit in my repo to fix this. The problem was, that moved directories do not get into the delete_refs loop and thus the parent of the old location is never added to the check_dirs list. I have force pushed to for-alex, if you have time I'd be happy if you test again :) Thanks. It fixes the issue. ...and pls expect another mail from me with a long list of questions I accumulated:) Thanks! Alex. -- 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-info.html
Re: severe hardlink bug
Am Sonntag, 24. Januar 2010 schrieb Michael Niederle: I'm using btrfs with a kernel 2.6.32.2 (builtin) as the root file system of a Gentoo Linux installation. Upgrade your kernel! This kernel is wy to old for any production use of BTRFS. Heck, upstream still did not mark BTRFS as stable although Oracle and SUSE do support it. Current kernel have a many fixes. Use at least 3.2. And have backups anyway. The hard-link issue is known since ages and being worked on (see link from Jan in this thread). If you want to help, test the patch. So, folks, can we get over it? Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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-info.html
segfault on mounting second device
Hi,
I was trying to mount two-disk btrfs without the first disk (the setup is RAID1
data metadata
on two disks). Kernel is 3.5.0-6-generic from Ubuntu.
[ 977.061470] device label HOME devid 2 transid 24686 /dev/sda3
[ 977.062992] btrfs: allowing degraded mounts
[ 977.063300] btrfs: disk space caching is enabled
[ 977.135840] btrfs: bdev (null) errs: wr 0, rd 0, flush 0, corrupt 0, gen 0
[ 977.136228] btrfs: bdev /dev/sda3 errs: wr 0, rd 0, flush 0, corrupt 0, gen 0
[ 977.888055] [drm] nouveau :00:0d.0: Setting dpms mode 1 on vga encoder
(output 0)
[ 981.401171] BUG: unable to handle kernel NULL pointer dereference at 0008
[ 981.401483] IP: [c116bb82] seq_escape+0x12/0xf0
[ 981.401752] *pdpt = 34f97001 *pde =
[ 981.402384] Oops: [#1] SMP
[ 981.402633] Modules linked in: netconsole configfs binfmt_misc arc4
snd_hda_codec_realtek nouveau mxm_wmi wmi snd_wavefront video ttm b43
snd_cs4236 drm_kms_helper drm i2c_algo_bit snd_opl3_lib snd_wss_lib bcma
snd_hda_intel mac80211 snd_hda_codec cfg80211 snd_hwdep pcspkr snd_mpu401
snd_pcm snd_mpu401_uart snd_page_alloc snd_rawmidi evbug snd_timer
snd_seq_device snd k8temp soundcore i2c_nforce2 parport_pc parport mac_hid
w83627ehf hwmon_vid autofs4 btrfs libcrc32c zlib_deflate usbhid hid ssb
forcedeth sata_sil pata_amd sata_nv [last unloaded: netconsole]
[ 981.404464]
[ 981.404464] Pid: 1, comm: systemd Not tainted 3.5.0-6-generic #6-Ubuntu To
Be Filled By O.E.M. To Be Filled By O.E.M./K8NF6G-VSTA
[ 981.404464] EIP: 0060:[c116bb82] EFLAGS: 00010286 CPU: 0
[ 981.404464] EIP is at seq_escape+0x12/0xf0
[ 981.404464] EAX: f703ca20 EBX: f73b2000 ECX: f862e8cb EDX: f703ca20
[ 981.404464] ESI: 0002 EDI: 0008 EBP: f4c79ebc ESP: f4c79ea0
[ 981.404464] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 981.404464] CR0: 80050033 CR2: 0008 CR3: 34f94000 CR4: 07f0
[ 981.404464] DR0: DR1: DR2: DR3:
[ 981.404464] DR6: 0ff0 DR7: 0400
[ 981.404464] Process systemd (pid: 1, ti=f4c78000 task=f4c7
task.ti=f4c78000)
[ 981.404464] Stack:
[ 981.404464] 0073 f4c79ec8 c116bc0b f4c79ebc f73b2000 0002
f4c79ed8
[ 981.404464] f859c3ac f73b2000 f703ca20 f4531010 f703ca20 f6bd8c00 f4c79f20
c1184b03
[ 981.404464] c177630e c1787722 0029 0014 0022 c112473d
fffbaa90
[ 981.404464] Call Trace:
[ 981.404464] [c116bc0b] ? seq_escape+0x9b/0xf0
[ 981.404464] [f859c3ac] btrfs_show_devname+0x8c/0xc0 [btrfs]
[ 981.404464] [c1184b03] show_mountinfo+0x173/0x260
[ 981.404464] [c112473d] ? handle_mm_fault+0x1dd/0x280
[ 981.404464] [c1168380] m_show+0x10/0x20
[ 981.404464] [c116bee5] seq_read+0xd5/0x3c0
[ 981.404464] [c116be10] ? seq_lseek+0x150/0x150
[ 981.404464] [c114efe9] vfs_read+0x89/0x160
[ 981.404464] [c116be10] ? seq_lseek+0x150/0x150
[ 981.404464] [c114f0fd] sys_read+0x3d/0x70
[ 981.404464] [c15c701f] sysenter_do_call+0x12/0x28
[ 981.404464] Code: 83 c3 01 39 fb 76 d0 66 90 31 db 83 c4 08 89 d8 5b 5e 5f
5d c3 8d 74 26 00 55 89 e5 57 56 53 83 ec 10 3e 8d 74 26 00 89 d7 89 c2 0f b6
37 8b 5a 0c 89 45 e8 8b 00 89 4d ec 8b 4a 04 89 f2 01 c3
[ 981.404464] EIP: [c116bb82] seq_escape+0x12/0xf0 SS:ESP 0068:f4c79ea0
[ 981.404464] CR2: 0008
[ 981.433876] [drm] nouveau :00:0d.0: Setting dpms mode 0 on vga encoder
(output 0)
[ 981.437631] ---[ end trace ec2ba853e06fd789 ]---
[ 981.438875] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0009
[ 981.438875]
[ 981.439741] panic occurred, switching back to text console
To my untrained eye, it looks like first_dev-name-str is NULL.
if (first_dev) {
rcu_read_lock();
name = rcu_dereference(first_dev-name);
seq_escape(m, name-str, \t\n\\);
rcu_read_unlock();
} else {
Zbyszek
--
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-info.html
Re: segfault on mounting second device
On Mon, Jul 30, 2012 at 12:25:01PM -0600, Zbigniew Jędrzejewski-Szmek wrote:
Hi,
I was trying to mount two-disk btrfs without the first disk (the setup is
RAID1 data metadata
on two disks). Kernel is 3.5.0-6-generic from Ubuntu.
[ 977.061470] device label HOME devid 2 transid 24686 /dev/sda3
[ 977.062992] btrfs: allowing degraded mounts
[ 977.063300] btrfs: disk space caching is enabled
[ 977.135840] btrfs: bdev (null) errs: wr 0, rd 0, flush 0, corrupt 0, gen 0
[ 977.136228] btrfs: bdev /dev/sda3 errs: wr 0, rd 0, flush 0, corrupt 0,
gen 0
[ 977.888055] [drm] nouveau :00:0d.0: Setting dpms mode 1 on vga encoder
(output 0)
[ 981.401171] BUG: unable to handle kernel NULL pointer dereference at
0008
[ 981.401483] IP: [c116bb82] seq_escape+0x12/0xf0
[ 981.401752] *pdpt = 34f97001 *pde =
[ 981.402384] Oops: [#1] SMP
[ 981.402633] Modules linked in: netconsole configfs binfmt_misc arc4
snd_hda_codec_realtek nouveau mxm_wmi wmi snd_wavefront video ttm b43
snd_cs4236 drm_kms_helper drm i2c_algo_bit snd_opl3_lib snd_wss_lib bcma
snd_hda_intel mac80211 snd_hda_codec cfg80211 snd_hwdep pcspkr snd_mpu401
snd_pcm snd_mpu401_uart snd_page_alloc snd_rawmidi evbug snd_timer
snd_seq_device snd k8temp soundcore i2c_nforce2 parport_pc parport mac_hid
w83627ehf hwmon_vid autofs4 btrfs libcrc32c zlib_deflate usbhid hid ssb
forcedeth sata_sil pata_amd sata_nv [last unloaded: netconsole]
[ 981.404464]
[ 981.404464] Pid: 1, comm: systemd Not tainted 3.5.0-6-generic #6-Ubuntu To
Be Filled By O.E.M. To Be Filled By O.E.M./K8NF6G-VSTA
[ 981.404464] EIP: 0060:[c116bb82] EFLAGS: 00010286 CPU: 0
[ 981.404464] EIP is at seq_escape+0x12/0xf0
[ 981.404464] EAX: f703ca20 EBX: f73b2000 ECX: f862e8cb EDX: f703ca20
[ 981.404464] ESI: 0002 EDI: 0008 EBP: f4c79ebc ESP: f4c79ea0
[ 981.404464] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 981.404464] CR0: 80050033 CR2: 0008 CR3: 34f94000 CR4: 07f0
[ 981.404464] DR0: DR1: DR2: DR3:
[ 981.404464] DR6: 0ff0 DR7: 0400
[ 981.404464] Process systemd (pid: 1, ti=f4c78000 task=f4c7
task.ti=f4c78000)
[ 981.404464] Stack:
[ 981.404464] 0073 f4c79ec8 c116bc0b f4c79ebc f73b2000 0002
f4c79ed8
[ 981.404464] f859c3ac f73b2000 f703ca20 f4531010 f703ca20 f6bd8c00
f4c79f20 c1184b03
[ 981.404464] c177630e c1787722 0029 0014 0022
c112473d fffbaa90
[ 981.404464] Call Trace:
[ 981.404464] [c116bc0b] ? seq_escape+0x9b/0xf0
[ 981.404464] [f859c3ac] btrfs_show_devname+0x8c/0xc0 [btrfs]
[ 981.404464] [c1184b03] show_mountinfo+0x173/0x260
[ 981.404464] [c112473d] ? handle_mm_fault+0x1dd/0x280
[ 981.404464] [c1168380] m_show+0x10/0x20
[ 981.404464] [c116bee5] seq_read+0xd5/0x3c0
[ 981.404464] [c116be10] ? seq_lseek+0x150/0x150
[ 981.404464] [c114efe9] vfs_read+0x89/0x160
[ 981.404464] [c116be10] ? seq_lseek+0x150/0x150
[ 981.404464] [c114f0fd] sys_read+0x3d/0x70
[ 981.404464] [c15c701f] sysenter_do_call+0x12/0x28
[ 981.404464] Code: 83 c3 01 39 fb 76 d0 66 90 31 db 83 c4 08 89 d8 5b 5e 5f
5d c3 8d 74 26 00 55 89 e5 57 56 53 83 ec 10 3e 8d 74 26 00 89 d7 89 c2 0f
b6 37 8b 5a 0c 89 45 e8 8b 00 89 4d ec 8b 4a 04 89 f2 01 c3
[ 981.404464] EIP: [c116bb82] seq_escape+0x12/0xf0 SS:ESP 0068:f4c79ea0
[ 981.404464] CR2: 0008
[ 981.433876] [drm] nouveau :00:0d.0: Setting dpms mode 0 on vga encoder
(output 0)
[ 981.437631] ---[ end trace ec2ba853e06fd789 ]---
[ 981.438875] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0009
[ 981.438875]
[ 981.439741] panic occurred, switching back to text console
To my untrained eye, it looks like first_dev-name-str is NULL.
if (first_dev) {
rcu_read_lock();
name = rcu_dereference(first_dev-name);
seq_escape(m, name-str, \t\n\\);
rcu_read_unlock();
} else {
Zbyszek
Hrm oops, I will fix that, thanks for reporting,
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-info.html
Re: btrfs send/receive: if new inode ino is less than its new directory ino, incorrect path is sent
On Mon, Jul 30, 2012 at 7:35 PM, Alex Lyakas alex.bolshoy.bt...@gmail.com wrote: Hi, I did not apply the patch but instead added a check for dir != tmp_dir only. The reason to not check for gen is that I have a rule in my mind: I only pass the generation number to functions where I want to know the *current* state. is_first_ref is for permanent state, the return value never changes while sending. I could however not reproduce the problem with test_1.sh, but it should fix it. I understand. I was not sure about dir_gen either. Since you call this function to check the permanent state in a particular root, it does not make sense to compare the generation. btrfs_test_2.sh The last test exposes an interesting issue: when a directory has a deleted reference recorded, this deleted reference is not added to the 'check_dirs' list. As a result, the upper directory (already orphanized) is not rmdir'd. You'll find a commit in my repo to fix this. The problem was, that moved directories do not get into the delete_refs loop and thus the parent of the old location is never added to the check_dirs list. I have force pushed to for-alex, if you have time I'd be happy if you test again :) Thanks. It fixes the issue. ...and pls expect another mail from me with a long list of questions I accumulated:) Do you have more bugs that you found or only questions? If you have more bugs, it would be good if you could separate them from the mail and probably send it earlier. Regarding your earlier question: Yes, for-alex is meant to go upstream before I leave. It will become for-chris and with a final pull request. Thanks! Alex. -- 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-info.html
Re: subvolumes: default and IDs
Hi Florian,
in case you would like to have some code references, to better
understand how it works:
1. Why is the default subvolid=5?
The trees in Btrfs all are referenced in the root tree by their
OBJECTIDs. You can find the definitions(magic numbers) for the
main trees in ctree.h:
For example, the main FS tree (you have one FS tree per subvolume) is
defined like this:
#define BTRFS_FS_TREE_OBJECTID 5ULL
== subvolid=5
2. Why can I mount with -o subvolid=0 succesfully, albeit the default
FS tree has subvolid=5?
Have a look at: linux/fs/btrfs/super.c
In early mount options parser: btrfs_parse_early_options
Snippet:
case Opt_subvolid:
intarg = 0;
error = match_int(args[0], intarg);
if (!error) {
/* we want the original fs_tree */
/*Here is the trick == */ if (!intarg)
*subvol_objectid =
BTRFS_FS_TREE_OBJECTID;
else
*subvol_objectid = intarg;
}
break;
== So, if intarg is still 0 after the match_int line, it will use
BTRFS_FS_TREE_OBJECTID (which we know from 1. being 5ULL) when
mounting.
Best Regards,
Alex
2012/7/30 Florian Lindner mailingli...@xgm.de:
Hey!
I recently starting playing with btrfs and subvolume, but it has left
me puzzled:
Distribution is Archlinux, Kernel is 3.4.6.
root@horus /mnt # mkfs.btrfs -L test /dev/sdb1
WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
fs created label test on /dev/sdb1
nodesize 4096 leafsize 4096 sectorsize 4096 size 2.73TB
Btrfs Btrfs v0.19
root@horus /mnt # mount /dev/sdb1 test
root@horus /mnt # cd test
root@horus /mnt/test # btrfs subvolume create sv1
Create subvolume './sv1'
root@horus /mnt/test # btrfs subvolume create sv2
Create subvolume './sv2'
root@horus /mnt/test # touch sv1/sv1.file
root@horus /mnt/test # touch sv2/sv2.file
root@horus /mnt/test # btrfs subvolume get-default .
ID 256 top level 5 path sv1
ID 259 top level 5 path sv2
What is the default subvolume now? How can I tell?
root@horus /mnt/test # btrfs subvolume set-default 259 .
root@horus /mnt/test # btrfs subvolume get-default .
ID 256 top level 5 path sv1
ID 259 top level 5 path sv2
Seems to have changed nothing?
root@horus /mnt/test # cd ..
root@horus /mnt # umount test mount /dev/sdb1 test
root@horus /mnt # ls test
sv2.file
Ah, sv2 seems to be default, like I had set it.
root@horus /mnt # btrfs subvolume set-default 5 test
root@horus /mnt # umount test /mnt # mount /dev/sdb1 test
root@horus /mnt # ls test
sv1/ sv2/
Ok, 5 seems to be the root subvolume id. Is it always like that? I
remembered to have read somewhere it was 0 ? (which makes a kind of
more sense for me)
root@horus /mnt # btrfs subvolume set-default 256 test
root@horus /mnt # umount test mount /dev/sdb1 test
root@horus /mnt # ls test
sv1.file
Fine! But:
root@horus /mnt # btrfs subvolume set-default 0 test
root@horus /mnt # umount test mount /dev/sdb1 test
root@horus /mnt # ls test
sv1.file
set-default 0 seems to do nothing but does not produce an error
either. What about subvolume 0? Still I can do:
root@horus /mnt # umount test
root@horus /mnt # mount -o subvolid=0 /dev/sdb1 test
root@horus /mnt # ls test
sv1/ sv2/
Ok, here 0 as subvolid works. What about subvolid=5?
root@horus /mnt # umount test
root@horus /mnt # mount -o subvolid=5 /dev/sdb1 test
root@horus /mnt # ls test
sv1/ sv2/
Works too.
Sorry for the lengthy posting, but writing this posting has puzzled me
even more I was yesterday. I hope someone could shed some light on it.
Thanks!
Florian
--
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-info.html
--
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-info.html
Re: subvolumes: default and IDs
Hi everybody, I believe Florian came across some odd behaviour of btrfs subvolume set-default which might still not be perfect in the current btrfs-progs: It does not seem to change the default subvolume to the original root fs tree if he does btrfs subvolume set-default 0 /path/to/fs. I am referring to this mail of Chris Mason where he said btrfs subvolume set-default 0 /path should set the default subvolume to the original root tree: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg04567.html either this was not implemented, yet, or I just didn't find it. So to answer Florians third question, and to provide a patch for discussion: 3. Why does btrfs subvolume set-default 0 /path/to/fs seemingly not change the default subvol? It goes like this: 3.1 Btrfs-progs: btrfs subvolume set-default 0 /path/to/fs lands in: do_set_default_subvol and ret = ioctl(fd, BTRFS_IOC_DEFAULT_SUBVOL, objectid); then sends the subvolid=0 to the kernel ioctl. 3.2 Kernel fs/btrfs: ioctl.c reveals the function to look at: long btrfs_ioctl(struct file *file, unsigned int cmd, unsigned long arg) ... case BTRFS_IOC_DEFAULT_SUBVOL: return btrfs_ioctl_default_subvol(file, argp); ... = static long btrfs_ioctl_default_subvol(struct file *file, void __user *argp) Here we got this: u64 objectid = 0; ... /* argp is the the pointer to the 0 supplied from btrfs subvolume set-default 0 ... */ if (copy_from_user(objectid, argp, sizeof(objectid))) return -EFAULT; /* as objectid now is 0, we use the current mounted subvolumes (FS tree) objectid */ if (!objectid) objectid = root-root_key.objectid; == So, btrfs subvolume set-default 0 /path/to/fs does in fact change the default subvolume, if the currently mounted subvolume is not the current default-subvolume. In Florian's example the subvolume seemingly did't change because he alway had the current default-subvolume mounted. IMHO, when following the principle of least surprise calling btrfs subvolume set-default 0 /path/to/fs should always change the default subvolume to be the root subvolume. This would actually establish the same behaviour as the automatic translation from 0ULL to 5ULL in mount -o subvolid=0. This can be done either in the kernel code(fs/btrfs/ioctl.c), by just exchanging: if (!objectid) -objectid = root-root_key.objectid; +objectid = BTRFS_FS_TREE_OBJECTID; Or in btrfs-tools, which I would prefer. I am gonna send a patch against the integration branch of btrfs-progs for discussion shortly. Best Regards, Alex 2012/7/30 Florian Lindner mailingli...@xgm.de Hey! I recently starting playing with btrfs and subvolume, but it has left me puzzled: Distribution is Archlinux, Kernel is 3.4.6. root@horus /mnt # mkfs.btrfs -L test /dev/sdb1 WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using fs created label test on /dev/sdb1 nodesize 4096 leafsize 4096 sectorsize 4096 size 2.73TB Btrfs Btrfs v0.19 root@horus /mnt # mount /dev/sdb1 test root@horus /mnt # cd test root@horus /mnt/test # btrfs subvolume create sv1 Create subvolume './sv1' root@horus /mnt/test # btrfs subvolume create sv2 Create subvolume './sv2' root@horus /mnt/test # touch sv1/sv1.file root@horus /mnt/test # touch sv2/sv2.file root@horus /mnt/test # btrfs subvolume get-default . ID 256 top level 5 path sv1 ID 259 top level 5 path sv2 What is the default subvolume now? How can I tell? root@horus /mnt/test # btrfs subvolume set-default 259 . root@horus /mnt/test # btrfs subvolume get-default . ID 256 top level 5 path sv1 ID 259 top level 5 path sv2 Seems to have changed nothing? root@horus /mnt/test # cd .. root@horus /mnt # umount test mount /dev/sdb1 test root@horus /mnt # ls test sv2.file Ah, sv2 seems to be default, like I had set it. root@horus /mnt # btrfs subvolume set-default 5 test root@horus /mnt # umount test /mnt # mount /dev/sdb1 test root@horus /mnt # ls test sv1/ sv2/ Ok, 5 seems to be the root subvolume id. Is it always like that? I remembered to have read somewhere it was 0 ? (which makes a kind of more sense for me) root@horus /mnt # btrfs subvolume set-default 256 test root@horus /mnt # umount test mount /dev/sdb1 test root@horus /mnt # ls test sv1.file Fine! But: root@horus /mnt # btrfs subvolume set-default 0 test root@horus /mnt # umount test mount /dev/sdb1 test root@horus /mnt # ls test sv1.file set-default 0 seems to do nothing but does not produce an error either. What about subvolume 0? Still I can do: root@horus /mnt # umount test root@horus /mnt # mount -o subvolid=0 /dev/sdb1 test root@horus /mnt # ls test sv1/ sv2/ Ok, here 0 as subvolid works. What about subvolid=5? root@horus /mnt # umount test root@horus /mnt # mount -o subvolid=5 /dev/sdb1 test root@horus
[PATCH] Btrfs-progs: Enabled setting root subvolume with subvolid=0
The command btrfs subvolume set-default 0 /path/to/fs changed the
default subvolume to whatever subvolume was currently mounted on
/path/to/fs. This patch changes this behaviour to set the default
subvolume to BTRFS_FS_TREE_OBJECTID in case the user asks for
subvolid=0
Signed-off-by: Alexander Karbstein alexander.karbst...@gmail.com
---
btrfs_cmds.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index f2b6355..699d9b0 100644
--- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -964,6 +964,11 @@ int do_set_default_subvol(int nargs, char **argv)
fprintf(stderr, ERROR: invalid tree id (%s)\n,subvolid);
return 30;
}
+
+ /* Using the original root fs tree */
+ if (objectid == 0ULL) {
+ objectid = BTRFS_FS_TREE_OBJECTID;
+ }
ret = ioctl(fd, BTRFS_IOC_DEFAULT_SUBVOL, objectid);
e = errno;
close(fd);
--
1.7.2.5
--
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-info.html
Re: Re: [PATCH 0/8] Set bi_rw when alloc bio before call bio_add_page.
On Tue, Jul 31, 2012 at 08:55:59AM +0800, majianpeng wrote:
On 2012-07-31 05:42 Dave Chinner da...@fromorbit.com Wrote:
On Mon, Jul 30, 2012 at 03:14:28PM +0800, majianpeng wrote:
When exec bio_alloc, the bi_rw is zero.But after calling bio_add_page,
it will use bi_rw.
Fox example, in functiion __bio_add_page,it will call merge_bvec_fn().
The merge_bvec_fn of raid456 will use the bi_rw to judge the merge.
if ((bvm-bi_rw 1) == WRITE)
return biovec-bv_len; /* always allow writes to be mergeable */
So if bio_add_page() requires bi_rw to be set, then shouldn't it be
set up for every caller? I noticed there are about 50 call sites for
bio_add_page(), and you've only touched about 10 of them. Indeed, I
notice that the RAID0/1 code uses bio_add_page, and as that can be
stacked on top of RAID456, it also needs to set bi_rw correctly.
As a result, your patch set is nowhere near complete, not does it
document that bio_add_page requires that bi_rw be set before calling
(which is the new API requirement, AFAICT).
There are many place call bio_add_page and I send some of those. Because my
abilty, so I only send
some patchs which i understand clearly.
Sure, but my point is that there is no point changing only a few and
ignoring the great majority of callers. Either fix them all, fix it
some other way (e.g. API change), or remove the code from the RAID5
function that requires it.
In __bio_add_page:
if (q-merge_bvec_fn) {
struct bvec_merge_data bvm = {
/* prev_bvec is already charged in
bi_size, discharge it in order to
simulate merging updated prev_bvec
as new bvec. */
.bi_bdev = bio-bi_bdev,
.bi_sector = bio-bi_sector,
.bi_size = bio-bi_size - prev_bv_len,
.bi_rw = bio-bi_rw,
};
it used bio-bi_rw.
Before raid5_mergeable_bvec appearing, in kernel 'merge_bvec_fn' did not use
bio-bi_rw.
Right, but as things stand right now, the RAID5 code is a no-op
because nobody is setting bio-bi_rw correctly. it is effectively
dead code.
But i think we shold not suppose bi_rw not meanless.
To decide whether we should take it to have meaning, data is
required to show that the RAID5 optimisation it enables is
worthwhile. If the optimisation is not worthwhile, then the correct
thing to do is remove the optimisation in the RAID5 code and remove
the bi_rw field from the struct bvec_merge_data.
So, my question is whether the RAID456 code is doing something
valid. That write optimisation is clearly not enabled for a
significant amount of code and filesystems, so the first thing to do
is quantify the benefit of the optimisation. I can't evalute the
merit of this change without data telling me it is worthwhile, and
it's a lot of code to churn for no benefit
Sorry, we do not think the 'merge_bvec_fn' did not use bi_rw.
It's entirely possible that when bi_rw was added to struct
bvec_merge_data, the person who added it was mistaken that bi_rw was
set at this point in time when in fact it never has been. Hence it's
presence and reliance on it would be a bug.
That's what I'm asking - is this actually beneificial, or should it
simply be removed from struct bvec_merge_data? Data is needed to
answer that question
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
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-info.html
Re: balance disables nodatacow
On 07/31/2012 03:55 AM, Kyle Gates wrote: I have a 3 disk raid1 filesystem mounted with nodatacow. I have a folder in said filesystem with the 'C' NOCOW 'Z' Not_Compressed flags set for good measure. I then copy in a large file and proceed to make random modifications. Filefrag shows no additional extents created, good so far. A big thank you to the those devs who got that working. However, after a balance run (which crashed btw), modifications to the file result in increasing extent counts, ie. no longer obeying nodatacow mount option nor the 'C' flag. I realize that a balance will cow the data but it should not disable the ability to make nodatacow inline changes to a file. I'm currently running 3.5.0 mainline Ubuntu kernel with the latest master of btrfs-progs from a ppa. hmm, I want to know if your 3.5.0 mainline ubuntu kernel has the commit: Btrfs: make btrfs's allocation smoothly with preallocation This commit may help you out of trouble. Please let us know the result. thanks, liubo Thank you. Kyle Gates -- 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-info.html -- 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-info.html
Re: balance disables nodatacow
On 07/31/2012 12:35 PM, Kyle Gates wrote:
On Mon, Jul 30, 2012 at 9:00 PM, Liu Bo liubo2...@cn.fujitsu.com wrote:
On 07/31/2012 03:55 AM, Kyle Gates wrote:
I have a 3 disk raid1 filesystem mounted with nodatacow. I have a
folder in said filesystem with the 'C' NOCOW 'Z' Not_Compressed
flags set for good measure. I then copy in a large file and proceed to
make random modifications. Filefrag shows no additional extents
created, good so far. A big thank you to the those devs who got that
working.
However, after a balance run (which crashed btw), modifications to the
file result in increasing extent counts, ie. no longer obeying
nodatacow mount option nor the 'C' flag.
I realize that a balance will cow the data but it should not disable
the ability to make nodatacow inline changes to a file.
I'm currently running 3.5.0 mainline Ubuntu kernel with the latest
master of btrfs-progs from a ppa.
hmm, I want to know if your 3.5.0 mainline ubuntu kernel has the commit:
Btrfs: make btrfs's allocation smoothly with preallocation
This commit may help you out of trouble.
Please let us know the result.
thanks,
liubo
Thank you.
Kyle Gates
I didn't have that commit before but I do now:
Linux home 3.5.0-999-generic #201207290405 SMP Sun Jul 29 08:13:26 UTC
2012 i686 athlon i386 GNU/Linux
One of my disk is having some issues though. I got this why running a
balance which is now hung:
oops, I know where goes wrong. I should have noticed it, sorry Kyle.
We've not merged the following patch into mainline:
Btrfs: allow delayed refs to be merged V2
(link: https://patchwork.kernel.org/patch/1197821/)
So could you please apply the patch and test it again?
thanks,
liubo
Jul 30 23:26:38 home kernel: [ 3809.072508] btrfs: found 43 extents
Jul 30 23:26:41 home kernel: [ 3811.987119] btrfs: found 43 extents
Jul 30 23:26:41 home kernel: [ 3812.264800] btrfs: relocating block
group 1270947512320 flags 17
Jul 30 23:26:55 home kernel: [ 3825.690152] ata3.00: exception Emask
0x0 SAct 0x0 SErr 0x0 action 0x0
Jul 30 23:26:55 home kernel: [ 3825.690161] ata3.00: BMDMA stat 0x64
Jul 30 23:26:55 home kernel: [ 3825.690166] ata3.00: failed command:
READ DMA EXT
Jul 30 23:26:55 home kernel: [ 3825.690174] ata3.00: cmd
25/00:00:00:44:2d/00:04:0c:00:00/e0 tag 0 dma 524288 in
Jul 30 23:26:55 home kernel: [ 3825.690174] res
51/40:00:bd:45:2d/40:00:0c:00:00/e0 Emask 0x9 (media error)
Jul 30 23:26:55 home kernel: [ 3825.690177] ata3.00: status: { DRDY ERR }
Jul 30 23:26:55 home kernel: [ 3825.690180] ata3.00: error: { UNC }
Jul 30 23:26:55 home kernel: [ 3825.712355] ata3.00: configured for UDMA/133
Jul 30 23:26:55 home kernel: [ 3825.712396] sd 2:0:0:0: [sdd]
Unhandled sense code
Jul 30 23:26:55 home kernel: [ 3825.712400] sd 2:0:0:0: [sdd]
Jul 30 23:26:55 home kernel: [ 3825.712402] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
Jul 30 23:26:55 home kernel: [ 3825.712405] sd 2:0:0:0: [sdd]
Jul 30 23:26:55 home kernel: [ 3825.712408] Sense Key : Medium Error
[current] [descriptor]
Jul 30 23:26:55 home kernel: [ 3825.712412] Descriptor sense data with
sense descriptors (in hex):
Jul 30 23:26:55 home kernel: [ 3825.712414] 72 03 11 04 00 00
00 0c 00 0a 80 00 00 00 00 00
Jul 30 23:26:55 home kernel: [ 3825.712424] 0c 2d 45 bd
Jul 30 23:26:55 home kernel: [ 3825.712429] sd 2:0:0:0: [sdd]
Jul 30 23:26:55 home kernel: [ 3825.712433] Add. Sense: Unrecovered
read error - auto reallocate failed
Jul 30 23:26:55 home kernel: [ 3825.712437] sd 2:0:0:0: [sdd] CDB:
Jul 30 23:26:55 home kernel: [ 3825.712439] Read(10): 28 00 0c 2d 44
00 00 04 00 00
Jul 30 23:26:55 home kernel: [ 3825.712448] end_request: I/O error,
dev sdd, sector 204293565
Jul 30 23:26:55 home kernel: [ 3825.712453] btrfs: bdev /dev/sdd6
errs: wr 0, rd 70, flush 0, corrupt 0, gen 0
Jul 30 23:26:55 home kernel: [ 3825.712457] btrfs: bdev /dev/sdd6
errs: wr 0, rd 71, flush 0, corrupt 0, gen 0
Jul 30 23:26:55 home kernel: [ 3825.712463] btrfs: bdev /dev/sdd6
errs: wr 0, rd 72, flush 0, corrupt 0, gen 0
Jul 30 23:26:55 home kernel: [ 3825.712466] btrfs: bdev /dev/sdd6
errs: wr 0, rd 73, flush 0, corrupt 0, gen 0
Jul 30 23:26:55 home kernel: [ 3825.712470] btrfs: bdev /dev/sdd6
errs: wr 0, rd 74, flush 0, corrupt 0, gen 0
Jul 30 23:26:55 home kernel: [ 3825.712484] ata3: EH complete
Jul 30 23:29:10 home kernel: [ 3960.660091] INFO: task btrfs:4600
blocked for more than 120 seconds.
Jul 30 23:29:10 home kernel: [ 3960.660099] echo 0
/proc/sys/kernel/hung_task_timeout_secs disables this message.
Jul 30 23:29:10 home kernel: [ 3960.660102] btrfs D f8540aba
0 4600 4598 0x
Jul 30 23:29:10 home kernel: [ 3960.660109] c5d2dc20 0082
c5d2dc28 f8540aba f55da048 c185f220 c198f080 c198f080
Jul 30 23:29:10 home kernel: [ 3960.660116] d3e86224 037a
f73f0080 cabe8000 f51cb2c0 f6dea000
Jul 30 23:29:10 home kernel: [ 3960.660122]
Re: filesystem finder / fixer
On Mon, 30 Jul 2012 23:26:42 -0400 (EDT) serial...@lavabit.com wrote: 1) is there a tool to help me recover data from my fs? I don't have a backup of my partition table and so I have about 500GB of space where a few partitionns might reside... GPT partitions mind you If you only lost the partition table, there's a tool (strangely)named TestDisk, which can find the actual partitions on disk and restore it. Don't know if it supports GPT and BTRFS, though. -- With respect, Roman ~~~ Stallman had a printer, with code he could not see. So he began to tinker, and set the software free. signature.asc Description: PGP signature
[PATCH 1/3 RESEND] Btrfs-progs: search subvolumes with proper objectid
Btrfs's subvolume/snapshot is limited to
[BTRFS_FIRST_FREE_OBJECTID, BTRFS_LAST_FREE_OBJECTID], so just apply the range.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
btrfs-list.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index c53d016..ac6507a 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -634,11 +634,13 @@ static int __list_subvol_search(int fd, struct
root_lookup *root_lookup)
sk-max_type = BTRFS_ROOT_BACKREF_KEY;
sk-min_type = BTRFS_ROOT_BACKREF_KEY;
+ sk-min_objectid = BTRFS_FIRST_FREE_OBJECTID;
+
/*
* set all the other params to the max, we'll take any objectid
* and any trans
*/
- sk-max_objectid = (u64)-1;
+ sk-max_objectid = BTRFS_LAST_FREE_OBJECTID;
sk-max_offset = (u64)-1;
sk-max_transid = (u64)-1;
@@ -690,7 +692,7 @@ static int __list_subvol_search(int fd, struct root_lookup
*root_lookup)
if (sk-min_type BTRFS_ROOT_BACKREF_KEY) {
sk-min_type = BTRFS_ROOT_BACKREF_KEY;
sk-min_offset = 0;
- } else if (sk-min_objectid (u64)-1) {
+ } else if (sk-min_objectid BTRFS_LAST_FREE_OBJECTID) {
sk-min_objectid++;
sk-min_type = BTRFS_ROOT_BACKREF_KEY;
sk-min_offset = 0;
--
1.6.5.2
--
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-info.html
[PATCH 3/3] Btrfs-progs: list snapshots by generation
The idea is that we usually use snapshot to backup/restore our data, and the
common way can be a cron script which makes lots of snapshots, so we can end
up with spending some time to find the latest snapshot to restore.
This adds a feature for 'btrfs subvolume list' to let it list snapshots by their
_created_ generation.
What we need to do is just to list them in descending order and get the latest
snapshot. What's more, we can find the oldest snapshot as well by listing
snapshots in ascending order.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
btrfs-list.c | 176 --
cmds-subvolume.c | 19 +-
2 files changed, 185 insertions(+), 10 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index 05360dc..0374b41 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -87,13 +87,23 @@ static int comp_entry(struct root_info *entry, u64 root_id,
u64 ref_tree)
return 0;
}
+static int comp_entry_with_gen(struct root_info *entry, u64 root_id,
+ u64 ref_tree, u64 gen)
+{
+ if (entry-gen gen)
+ return 1;
+ if (entry-gen gen)
+ return -1;
+ return comp_entry(entry, root_id, ref_tree);
+}
+
/*
* insert a new root into the tree. returns the existing root entry
* if one is already there. Both root_id and ref_tree are used
* as the key
*/
static struct rb_node *tree_insert(struct rb_root *root, u64 root_id,
- u64 ref_tree, struct rb_node *node)
+ u64 ref_tree, u64 *gen, struct rb_node *node)
{
struct rb_node ** p = root-rb_node;
struct rb_node * parent = NULL;
@@ -104,7 +114,11 @@ static struct rb_node *tree_insert(struct rb_root *root,
u64 root_id,
parent = *p;
entry = rb_entry(parent, struct root_info, rb_node);
- comp = comp_entry(entry, root_id, ref_tree);
+ if (!gen)
+ comp = comp_entry(entry, root_id, ref_tree);
+ else
+ comp = comp_entry_with_gen(entry, root_id, ref_tree,
+ *gen);
if (comp 0)
p = (*p)-rb_left;
@@ -171,7 +185,7 @@ static struct root_info *tree_search(struct rb_root *root,
u64 root_id)
*/
static int add_root(struct root_lookup *root_lookup,
u64 root_id, u64 ref_tree, u64 dir_id, char *name,
- int name_len)
+ int name_len, u64 *gen)
{
struct root_info *ri;
struct rb_node *ret;
@@ -185,11 +199,15 @@ static int add_root(struct root_lookup *root_lookup,
ri-dir_id = dir_id;
ri-root_id = root_id;
ri-ref_tree = ref_tree;
- strncpy(ri-name, name, name_len);
+ if (name)
+ strncpy(ri-name, name, name_len);
if (name_len 0)
ri-name[name_len] = 0;
+ if (gen)
+ ri-gen = *gen;
- ret = tree_insert(root_lookup-root, root_id, ref_tree, ri-rb_node);
+ ret = tree_insert(root_lookup-root, root_id, ref_tree, gen,
+ ri-rb_node);
if (ret) {
printf(failed to insert tree %llu\n, (unsigned long
long)root_id);
exit(1);
@@ -693,7 +711,7 @@ again:
dir_id = btrfs_stack_root_ref_dirid(ref);
add_root(root_lookup, sh-objectid, sh-offset,
-dir_id, name, name_len);
+dir_id, name, name_len, NULL);
} else if (get_gen sh-type == BTRFS_ROOT_ITEM_KEY) {
ri = (struct btrfs_root_item *)(args.buf + off);
gen = btrfs_root_generation(ri);
@@ -750,6 +768,79 @@ again:
return 0;
}
+static int __list_snapshot_search(int fd, struct root_lookup *root_lookup)
+{
+ int ret;
+ struct btrfs_ioctl_search_args args;
+ struct btrfs_ioctl_search_key *sk = args.key;
+ struct btrfs_ioctl_search_header *sh;
+ unsigned long off = 0;
+ u64 gen = 0;
+ int i;
+
+ root_lookup_init(root_lookup);
+ memset(args, 0, sizeof(args));
+
+ sk-tree_id = 1;
+ sk-max_type = BTRFS_ROOT_ITEM_KEY;
+ sk-min_type = BTRFS_ROOT_ITEM_KEY;
+ sk-min_objectid = BTRFS_FIRST_FREE_OBJECTID;
+ sk-max_objectid = BTRFS_LAST_FREE_OBJECTID;
+ sk-max_offset = (u64)-1;
+ sk-max_transid = (u64)-1;
+ sk-nr_items = 4096;
+
+ while (1) {
+ ret = ioctl(fd, BTRFS_IOC_TREE_SEARCH, args);
+ if (ret 0)
+ return ret;
+ /* the ioctl returns the number of item it found in nr_items */
+ if (sk-nr_items == 0)
+ break;
+
+ off = 0;
+
+ /*
+
[PATCH 2/3 RESEND] Btrfs-progs: show generation in command btrfs subvol list
This adds the ability to show root's modification generation when we use
btrfs subvol list.
NOTE:
Like file's atime and ctime, root's generation also has 'creation generation'
and 'modification generation'.
The generation that we're going to show is 'modification generation', and the
next patch is going to show 'creation generation'.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
btrfs-list.c | 61 -
1 files changed, 55 insertions(+), 6 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index ac6507a..05360dc 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -57,6 +57,9 @@ struct root_info {
/* the dir id we're in from ref_tree */
u64 dir_id;
+ /* generation when the root is created or last updated */
+ u64 gen;
+
/* path from the subvol we live in to this root, including the
* root's name. This is null until we do the extra lookup ioctl.
*/
@@ -194,6 +197,19 @@ static int add_root(struct root_lookup *root_lookup,
return 0;
}
+static int update_root(struct root_lookup *root_lookup, u64 root_id, u64 gen)
+{
+ struct root_info *ri;
+
+ ri = tree_search(root_lookup-root, root_id);
+ if (!ri || ri-root_id != root_id) {
+ fprintf(stderr, could not find subvol %llu\n, root_id);
+ return -ENOENT;
+ }
+ ri-gen = gen;
+ return 0;
+}
+
/*
* for a given root_info, search through the root_lookup tree to construct
* the full path name to it.
@@ -615,11 +631,15 @@ static int __list_subvol_search(int fd, struct
root_lookup *root_lookup)
struct btrfs_ioctl_search_key *sk = args.key;
struct btrfs_ioctl_search_header *sh;
struct btrfs_root_ref *ref;
+ struct btrfs_root_item *ri;
unsigned long off = 0;
int name_len;
char *name;
u64 dir_id;
+ u8 type;
+ u64 gen = 0;
int i;
+ int get_gen = 0;
root_lookup_init(root_lookup);
memset(args, 0, sizeof(args));
@@ -644,6 +664,7 @@ static int __list_subvol_search(int fd, struct root_lookup
*root_lookup)
sk-max_offset = (u64)-1;
sk-max_transid = (u64)-1;
+again:
/* just a big number, doesn't matter much */
sk-nr_items = 4096;
@@ -665,7 +686,7 @@ static int __list_subvol_search(int fd, struct root_lookup
*root_lookup)
sh = (struct btrfs_ioctl_search_header *)(args.buf +
off);
off += sizeof(*sh);
- if (sh-type == BTRFS_ROOT_BACKREF_KEY) {
+ if (!get_gen sh-type == BTRFS_ROOT_BACKREF_KEY) {
ref = (struct btrfs_root_ref *)(args.buf + off);
name_len = btrfs_stack_root_ref_name_len(ref);
name = (char *)(ref + 1);
@@ -673,6 +694,11 @@ static int __list_subvol_search(int fd, struct root_lookup
*root_lookup)
add_root(root_lookup, sh-objectid, sh-offset,
dir_id, name, name_len);
+ } else if (get_gen sh-type == BTRFS_ROOT_ITEM_KEY) {
+ ri = (struct btrfs_root_item *)(args.buf + off);
+ gen = btrfs_root_generation(ri);
+
+ update_root(root_lookup, sh-objectid, gen);
}
off += sh-len;
@@ -689,17 +715,38 @@ static int __list_subvol_search(int fd, struct
root_lookup *root_lookup)
/* this iteration is done, step forward one root for the next
* ioctl
*/
- if (sk-min_type BTRFS_ROOT_BACKREF_KEY) {
- sk-min_type = BTRFS_ROOT_BACKREF_KEY;
+ if (get_gen)
+ type = BTRFS_ROOT_ITEM_KEY;
+ else
+ type = BTRFS_ROOT_BACKREF_KEY;
+
+ if (sk-min_type type) {
+ sk-min_type = type;
sk-min_offset = 0;
} else if (sk-min_objectid BTRFS_LAST_FREE_OBJECTID) {
sk-min_objectid++;
- sk-min_type = BTRFS_ROOT_BACKREF_KEY;
+ sk-min_type = type;
sk-min_offset = 0;
} else
break;
}
+ if (!get_gen) {
+ memset(args, 0, sizeof(args));
+
+ sk-tree_id = 1;
+ sk-max_type = BTRFS_ROOT_ITEM_KEY;
+ sk-min_type = BTRFS_ROOT_ITEM_KEY;
+
+ sk-min_objectid = BTRFS_FIRST_FREE_OBJECTID;
+
+ sk-max_objectid = BTRFS_LAST_FREE_OBJECTID;
+ sk-max_offset = (u64)-1;
+ sk-max_transid = (u64)-1;
+
+ get_gen = 1;
+
