Re: btrfs userland interface isn't 32/64bit clean (breaks lsattr and btrfs send)
On Mon, Feb 24, 2014 at 06:32:14AM +, Duncan wrote: Marc MERLIN posted on Sun, 23 Feb 2014 21:51:03 -0800 as excerpted: In the end I pinned it down to this: 3.13.5's kernel/userland interface fails if my kernel is 64bit and my userland 32bit. This is a known issue. There's patches in the pipeline for 32-bit userspace on a 64-bit kernel, already. If you mean my recent patch, that's only for receive. I've not noticed any other issues on my 32/64 system, but I've not done much with it either (with btrfs, it's only really used for btrfs receive -- everything else is ext4). Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Welcome to Hollywood, a land just off the coast --- of Planet Earth. signature.asc Description: Digital signature
Re: btrfs userland interface isn't 32/64bit clean (breaks lsattr and btrfs send)
Hugo Mills posted on Mon, 24 Feb 2014 08:29:38 + as excerpted: On Mon, Feb 24, 2014 at 06:32:14AM +, Duncan wrote: This is a known issue. There's patches in the pipeline for 32-bit userspace on a 64-bit kernel, already. If you mean my recent patch, that's only for receive. I've not noticed any other issues on my 32/64 system, but I've not done much with it either (with btrfs, it's only really used for btrfs receive -- everything else is ext4). Thanks. Yes, I believe that's what I had in mind. So apparently there's more needed. (I /think/ I might have seen at least one additional patch float by for 32/64, but as it's out of my usage domain I'm not paying /that/ much attention to it, so perhaps not.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- 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 for xfstests] xfstests: fix to make tests/btrfs/013 really work
The test 013 couldn't work because here lacked start. This patch fix it. Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com --- tests/btrfs/013 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/btrfs/013 b/tests/btrfs/013 index 7620fcc..fb81663 100644 --- a/tests/btrfs/013 +++ b/tests/btrfs/013 @@ -72,7 +72,7 @@ _check_csum_error() } $XFS_IO_PROG -f -c falloc 0 1M -c pwrite 16k 8k -c fsync \ $SCRATCH_MNT/foo $seqres.full 21 -$BTRFS_UTIL_PROG filesystem balance $SCRATCH_MNT $seqres.full 21 || \ +$BTRFS_UTIL_PROG filesystem balance start $SCRATCH_MNT $seqres.full 21 || \ _fail balance failed _scratch_unmount _scratch_mount -- 1.8.1.4 . ___ kernel.openeuler mailing list kernel.openeu...@huawei.com http://rnd-openeuler.huawei.com/mailman/listinfo/kernel.openeuler -- 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 for xfstests] xfstests: fix to make tests/btrfs/013 really work
Hi Zhang, On 02/24/2014 06:51 PM, ZhangZhen wrote: The test 013 couldn't work because here lacked start. This patch fix it. Signed-off-by: Zhang Zhenzhenzhang.zh...@huawei.com --- tests/btrfs/013 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/btrfs/013 b/tests/btrfs/013 index 7620fcc..fb81663 100644 --- a/tests/btrfs/013 +++ b/tests/btrfs/013 @@ -72,7 +72,7 @@ _check_csum_error() } $XFS_IO_PROG -f -c falloc 0 1M -c pwrite 16k 8k -c fsync \ $SCRATCH_MNT/foo $seqres.full 21 -$BTRFS_UTIL_PROG filesystem balance $SCRATCH_MNT $seqres.full 21 || \ +$BTRFS_UTIL_PROG filesystem balance start $SCRATCH_MNT $seqres.full 21 || \ _fail balance failed Due to historical reasons, we have 'btrfs file balance '.. Until now, it is also ok to run 'btrfs file balance mnt', and it has equal effect as 'btrfs filesystem balance start'. Anyway, using latest 'btrfs file balance start mnt' is better than previous codes..but patch's title is not right any more... BTW,Dave Chinner previously pointed out that we need a cleanup, url can be seen: http://oss.sgi.com/archives/xfs/2014-02/msg00482.html Thanks, Wang _scratch_unmount _scratch_mount -- 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 v2] btrfs-progs: there is devid 0 when replace is running
kindly ignore this patch. Though it correct that we need to
start from devid 0 to scan. But the individual scan is broken
well before this patch. So to fix all together a patch bundle
is sent to the mailing list including this
Thanks Anand
On 02/04/14 04:33 PM, Anand Jain wrote:
During disk replacement a new disk is temporarily
added to the fs devlist with devid 0 and fs num_device is
incremented by 1. However when progs reads the devlist it
fail to obtain details of devid 0 because it doesn't query
devid 0 at all.
reproducer:
btrfs rep start /dev/sdb /dev/sdf /btrfs
btrfs fi show
Label: none uuid: f8fb9819-16c8-47b7-b62f-0ff90f8c56cd
Total devices 3 FS bytes used 1.94GiB
devid1 size 1.10GiB used 1.10GiB path /dev/sdb
devid2 size 1.10GiB used 1.08GiB path /dev/sdc
devid0 size 0.00 used 0.00 path
this patch will make it proper by querying devid 0.
btrfs repl start /dev/sdb /dev/sdf /btrfs
btrfs fi show /btrfs
Label: none uuid: f8fb9819-16c8-47b7-b62f-0ff90f8c56cd
Total devices 3 FS bytes used 1.94GiB
devid0 size 1.10GiB used 1.10GiB path /dev/sdf
devid1 size 1.10GiB used 1.10GiB path /dev/sdb
devid2 size 1.10GiB used 1.08GiB path /dev/sdc
Its fine to query devid 0 when there is no replace
activity as well, because we just skip the error ENODEV
btrfs fi show /btrfs
Label: none uuid: f8fb9819-16c8-47b7-b62f-0ff90f8c56cd
Total devices 2 FS bytes used 1.94GiB
devid1 size 1.10GiB used 1.10GiB path /dev/sdf
devid2 size 1.10GiB used 1.08GiB path /dev/sdc
---
v2: fix commit message
utils.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/utils.c b/utils.c
index de513b6..a045ffd 100644
--- a/utils.c
+++ b/utils.c
@@ -1696,7 +1696,7 @@ int get_fs_info(char *path, struct
btrfs_ioctl_fs_info_args *fi_args,
goto out;
}
- for (; i = fi_args-max_id; ++i) {
+ for (i = 0; i = fi_args-max_id; ++i) {
BUG_ON(ndevs = fi_args-num_devices);
ret = get_device_info(fd, i, di_args[ndevs]);
if (ret == -ENODEV)
--
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: Fix bug when scanned for devid which was missing and deleted
get_fs_info() provides the info of the specific
device/devid, however when we delete the missing disk
the super-block on the disk isn't cleared, and since
btrfs-progs makes its decision by reading the disk super
block, so it doesn't know about the kernel previous action,
And now when we tried to probe kernel for the devid it fails.
reproducer:
$ mkfs.btrfs -d raid1 -m raid1 /dev/sde /dev/sdf
$ modprobe -r btrfs modprobe btrfs
$ mount -o degraded /dev/sde /btrfs
$ btrfs dev add /dev/sdd /btrfs
$ btrfs dev del missing /btrfs
$ btrfs scrub start -B /dev/sdf
btrfs: utils.c:1741: get_fs_info: Assertion `!(ndevs == 0)' failed.
Aborted (core dumped)
Signed-off-by: Anand Jain anand.j...@oracle.com
---
utils.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/utils.c b/utils.c
index 231031e..bce92ab 100644
--- a/utils.c
+++ b/utils.c
@@ -1726,8 +1726,15 @@ int get_fs_info(char *path, struct
btrfs_ioctl_fs_info_args *fi_args,
ndevs++;
}
- BUG_ON(ndevs == 0);
- ret = 0;
+ /*
+ * only when the only dev we wanted to find is not there then
+ * let any error be returned
+ */
+ if (fi_args-num_devices != 1) {
+ BUG_ON(ndevs == 0);
+ ret = 0;
+ }
+
out:
close_file_or_dir(fd, dirstream);
return ret;
--
1.8.4.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 1/3 v3] btrfs-progs: there is devid 0 when replace is running
From: Anand Jain anand.j...@oracle.com as of now, when we replace a disk, it is added to the dev list with devid 0. And we fail to obtain details of devid 0 because we don't query devid 0 at all. reproducer: btrfs rep start /dev/sdb /dev/sdf /btrfs btrfs fi show Label: none uuid: f8fb9819-16c8-47b7-b62f-0ff90f8c56cd Total devices 3 FS bytes used 1.94GiB devid1 size 1.10GiB used 1.10GiB path /dev/sdb devid2 size 1.10GiB used 1.08GiB path /dev/sdc devid0 size 0.00 used 0.00 path this patch will make it proper by querying devid 0. btrfs repl start /dev/sdb /dev/sdf /btrfs btrfs fi show /btrfs Label: none uuid: f8fb9819-16c8-47b7-b62f-0ff90f8c56cd Total devices 3 FS bytes used 1.94GiB devid0 size 1.10GiB used 1.10GiB path /dev/sdf devid1 size 1.10GiB used 1.10GiB path /dev/sdb devid2 size 1.10GiB used 1.08GiB path /dev/sdc Its fine to query devid 0 when there is no replace activity as well, because we just skip the error ENODEV btrfs fi show /btrfs Label: none uuid: f8fb9819-16c8-47b7-b62f-0ff90f8c56cd Total devices 2 FS bytes used 1.94GiB devid1 size 1.10GiB used 1.10GiB path /dev/sdf devid2 size 1.10GiB used 1.08GiB path /dev/sdc Signed-off-by: Anand Jain anand.j...@oracle.com --- v3: it needs to handle per devid probe v2: commit message fix utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/utils.c b/utils.c index de513b6..e0c750d 100644 --- a/utils.c +++ b/utils.c @@ -1637,7 +1637,7 @@ int get_fs_info(char *path, struct btrfs_ioctl_fs_info_args *fi_args, int fd = -1; int ret = 0; int ndevs = 0; - int i = 1; + int i = 0; struct btrfs_fs_devices *fs_devices_mnt = NULL; struct btrfs_ioctl_dev_info_args *di_args; char mp[BTRFS_PATH_NAME_MAX + 1]; -- 1.8.4.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 v2] btrfs: introduce BTRFS_IOC_GET_DEVS
From: Anand Jain anand.j...@oracle.com
The user land progs needs a simple way to see
the raw list of disks and its parameters as seen
by the btrfs kernel.
As of now btrfs-devlist uses this ioctl.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
v2: add more parameter to get from the kernel
fs/btrfs/super.c | 56 ++
fs/btrfs/volumes.c | 140 +
fs/btrfs/volumes.h | 2 +
include/uapi/linux/btrfs.h | 49
4 files changed, 247 insertions(+)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index afb719e..f3c0247 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1717,6 +1717,59 @@ static struct file_system_type btrfs_fs_type = {
};
MODULE_ALIAS_FS(btrfs);
+static int btrfs_ioc_get_devlist(void __user *arg)
+{
+ int ret = 0;
+ u64 sz_devlist_arg;
+ u64 sz_devlist;
+ u64 sz_out;
+
+ struct btrfs_ioctl_devlist_args *devlist_arg;
+ struct btrfs_ioctl_devlist_args *tmp_devlist_arg;
+ struct btrfs_ioctl_devlist *devlist;
+
+ u64 cnt = 0, ucnt;
+
+ sz_devlist_arg = sizeof(*devlist_arg);
+ sz_devlist = sizeof(*devlist);
+
+ if (copy_from_user(ucnt,
+ (struct btrfs_ioctl_devlist_args __user *)(arg +
+ offsetof(struct btrfs_ioctl_devlist_args, count)),
+ sizeof(ucnt)))
+ return -EFAULT;
+
+ cnt = btrfs_get_devlist_cnt();
+
+ if (cnt ucnt) {
+ if (copy_to_user(arg +
+ offsetof(struct btrfs_ioctl_devlist_args, count),
+ cnt, sizeof(cnt)))
+ return -EFAULT;
+ return 1;
+ }
+
+ sz_out = sz_devlist_arg + sz_devlist * cnt;
+
+ tmp_devlist_arg = devlist_arg = memdup_user(arg, sz_out);
+ if (IS_ERR(devlist_arg))
+ return PTR_ERR(devlist_arg);
+
+ devlist = (struct btrfs_ioctl_devlist *) (++tmp_devlist_arg);
+ cnt = btrfs_get_devlist(devlist, cnt);
+ devlist_arg-count = cnt;
+
+ if (copy_to_user(arg, devlist_arg, sz_out)) {
+ ret = -EFAULT;
+ goto out;
+ }
+ ret = 0;
+out:
+ kfree(devlist_arg);
+ return ret;
+
+}
+
static int btrfs_ioc_get_fslist(void __user *arg)
{
int ret = 0;
@@ -1801,6 +1854,9 @@ static long btrfs_control_ioctl(struct file *file,
unsigned int cmd,
case BTRFS_IOC_GET_FSLIST:
ret = btrfs_ioc_get_fslist(argp);
break;
+ case BTRFS_IOC_GET_DEVS:
+ ret = btrfs_ioc_get_devlist(argp);
+ break;
}
return ret;
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 253fd9f..3c44800 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -6338,3 +6338,143 @@ u64 btrfs_get_fslist(struct btrfs_ioctl_fslist *fslist,
u64 ucnt)
return cnt;
}
+
+int btrfs_get_devlist_cnt(void)
+{
+ int cnt = 0;
+ struct btrfs_device *device;
+ struct btrfs_fs_devices *fs_devices;
+ struct btrfs_fs_devices *cur_fs_devices;
+
+ mutex_lock(uuid_mutex);
+ list_for_each_entry(cur_fs_devices, fs_uuids, list) {
+
+ fs_devices = cur_fs_devices;
+again_dev_cnt:
+ list_for_each_entry(device, fs_devices-devices, dev_list)
+ cnt++;
+
+ fs_devices = fs_devices-seed;
+ if (fs_devices)
+ goto again_dev_cnt;
+ }
+
+ mutex_unlock(uuid_mutex);
+
+ return cnt;
+}
+
+u64 btrfs_get_devlist(struct btrfs_ioctl_devlist *dev, u64 alloc_cnt)
+{
+ u64 cnt = 0;
+
+ struct btrfs_device *device;
+ struct btrfs_fs_devices *fs_devices;
+ struct btrfs_fs_devices *cur_fs_devices;
+ struct btrfs_fs_devices *sprout_fs_devices;
+
+ mutex_lock(uuid_mutex);
+ /* Todo: there must be better way of doing this */
+ list_for_each_entry(cur_fs_devices, fs_uuids, list) {
+
+ mutex_lock(cur_fs_devices-device_list_mutex);
+
+ fs_devices = cur_fs_devices;
+ sprout_fs_devices = NULL;
+
+again_dev:
+ list_for_each_entry(device, fs_devices-devices, dev_list) {
+
+ if (!(cnt alloc_cnt))
+ break;
+
+ memcpy(dev-fsid, fs_devices-fsid, BTRFS_FSID_SIZE);
+
+ if (fs_devices-seed)
+ memcpy(dev-seed_fsid, fs_devices-seed-fsid,
+ BTRFS_FSID_SIZE);
+ else
+ memset(dev-seed_fsid, 0, BTRFS_FSID_SIZE);
+
+ if (sprout_fs_devices)
+ memcpy(dev-sprout_fsid,
sprout_fs_devices-fsid,
+ BTRFS_FSID_SIZE);
+ else
+
[PATCH v2] btrfs-progs: introduce btrfs-devlist
From: Anand Jain anand.j...@oracle.com
This is a small (debug) program to dump the device list
in the raw format from the btrfs kernel.
here I use ioctl which was introduced in the below kernel
patch
btrfs: introduce BTRFS_IOC_GET_DEVS
Signed-off-by: Anand Jain anand.j...@oracle.com
---
v2: add more parameter to get from the kernel
.gitignore | 1 +
Makefile| 4 +-
btrfs-devlist.c | 249
ioctl.h | 49 +++
4 files changed, 301 insertions(+), 2 deletions(-)
create mode 100644 btrfs-devlist.c
diff --git a/.gitignore b/.gitignore
index ab8b81c..0928374 100644
--- a/.gitignore
+++ b/.gitignore
@@ -34,3 +34,4 @@ libbtrfs.a
libbtrfs.so
libbtrfs.so.0
libbtrfs.so.0.1
+btrfs-devlist
diff --git a/Makefile b/Makefile
index f99ca7c..2a52c17 100644
--- a/Makefile
+++ b/Makefile
@@ -47,7 +47,7 @@ MAKEOPTS = --no-print-directory Q=$(Q)
progs = mkfs.btrfs btrfs-debug-tree btrfsck \
btrfs btrfs-map-logical btrfs-image btrfs-zero-log btrfs-convert \
- btrfs-find-root btrfstune btrfs-show-super
+ btrfs-find-root btrfstune btrfs-show-super btrfs-devlist
# external libs required by various binaries; for btrfs-foo,
# specify btrfs_foo_libs = list of libs; see $($(subst...)) rules below
@@ -226,7 +226,7 @@ clean: $(CLEANDIRS)
@echo Cleaning
$(Q)rm -f $(progs) cscope.out *.o *.o.d btrfs-convert btrfs-image
btrfs-select-super \
btrfs-zero-log btrfstune dir-test ioctl-test quick-test send-test
btrfsck \
- btrfs.static mkfs.btrfs.static btrfs-calc-size \
+ btrfs.static mkfs.btrfs.static btrfs-calc-size btrfs-devlist\
version.h $(check_defs) \
$(libs) $(lib_links)
diff --git a/btrfs-devlist.c b/btrfs-devlist.c
new file mode 100644
index 000..baaca17
--- /dev/null
+++ b/btrfs-devlist.c
@@ -0,0 +1,249 @@
+/*
+ * Copyright (C) 2014 Oracle. 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 v2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will 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 to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include unistd.h
+#include getopt.h
+#include fcntl.h
+#include sys/ioctl.h
+#include uuid/uuid.h
+
+#include ctree.h
+#include ioctl.h
+#include commands.h
+#include utils.h
+
+void print_header(void)
+{
+ printf(
+ fsid \
+ name \
+ uuid \
+ (seed_fsid \
+ sprout_fsid) \n\
+ \t(fs_latest_devid \
+ fs_num_devices \
+ fs_open_devices \
+ fs_rw_devices \
+ fs_missing_devices \
+ fs_total_devices) \
+ fs_total_rw_bytes \
+ fs_num_can_discard \
+ fs_latest_trans \n\
+ \tdevid \
+ gen \
+ total_bytes \
+ disk_total_bytes \
+ bytes_used \
+ type \
+ io_align \
+ io_width \
+ sector_size \
+ fmode \n\
+ \tfs_flags\n\
+ \tdev_flags\n);
+}
+
+void print_dev(struct btrfs_ioctl_devlist *dev)
+{
+ char uuid[BTRFS_UUID_UNPARSED_SIZE];
+ char fsid[BTRFS_UUID_UNPARSED_SIZE];
+ char seed_fsid[BTRFS_UUID_UNPARSED_SIZE];
+ char sprout_fsid[BTRFS_UUID_UNPARSED_SIZE];
+
+ memset(seed_fsid, '0', BTRFS_UUID_UNPARSED_SIZE);
+ strcpy(seed_fsid, null);
+ memset(sprout_fsid, '0', BTRFS_UUID_UNPARSED_SIZE);
+ strcpy(sprout_fsid, null);
+
+ uuid_unparse(dev-uuid, uuid);
+ uuid_unparse(dev-fsid, fsid);
+ if (! uuid_is_null(dev-seed_fsid))
+ uuid_unparse(dev-seed_fsid, seed_fsid);
+ if (! uuid_is_null(dev-sprout_fsid))
+ uuid_unparse(dev-sprout_fsid, sprout_fsid);
+
+ printf(\n%s %s %s (%s %s)\n\
+ \t(%llu %llu %llu %llu %llu %llu) %llu %llu %llu\n\
+ \t%llu %llu %llu %llu %llu %llu %u %u %u 0x%llX\n\
+ \t%s|%s|%s\n\
+ \t%s|%s|%s|%s|%s|%s|%s|%s|%s|%s\n,
+ fsid,
+ dev-name,
+ uuid,
+ seed_fsid,
+ sprout_fsid,
+ dev-fs_latest_devid,
+ dev-fs_num_devices,
+ dev-fs_open_devices,
+ dev-fs_rw_devices,
+ dev-fs_missing_devices,
+ dev-fs_total_devices,
+
[PATCH v2] xfstests: add test for btrfs send issuing premature rmdir operations
Regression test for btrfs incremental send issue where a rmdir instruction
is sent against an orphan directory inode which is not empty yet, causing
btrfs receive to fail when it attempts to remove the directory.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: fix send attempting to rmdir non-empty directories
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
V2: Some cleanup as suggested by Dave Chinner. Use _check_scratch_fs() and
removed redundant stderr redirection when calling fssum via run_check.
tests/btrfs/041 | 152 +++
tests/btrfs/041.out |1 +
tests/btrfs/group |1 +
3 files changed, 154 insertions(+)
create mode 100755 tests/btrfs/041
create mode 100644 tests/btrfs/041.out
diff --git a/tests/btrfs/041 b/tests/btrfs/041
new file mode 100755
index 000..bfc0e4b
--- /dev/null
+++ b/tests/btrfs/041
@@ -0,0 +1,152 @@
+#! /bin/bash
+# FS QA Test No. btrfs/041
+#
+# Regression test for btrfs incremental send issue where a rmdir instruction
+# is sent against an orphan directory inode which is not empty yet, causing
+# btrfs receive to fail when it attempts to remove the directory.
+#
+# This issue is fixed by the following linux kernel btrfs patch:
+#
+# Btrfs: fix send attempting to rmdir non-empty directories
+#
+#---
+# Copyright (c) 2014 Filipe Manana. 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
+#---
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo QA output created by $seq
+
+here=`pwd`
+tmp=`mktemp -d`
+status=1 # failure is the default!
+trap _cleanup; exit \$status 0 1 2 3 15
+
+_cleanup()
+{
+rm -fr $tmp
+}
+
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+
+# real QA test starts here
+_supported_fs btrfs
+_supported_os Linux
+_require_scratch
+_need_to_be_root
+
+FSSUM_PROG=$here/src/fssum
+[ -x $FSSUM_PROG ] || _notrun fssum not built
+
+rm -f $seqres.full
+
+_scratch_mkfs /dev/null 21
+_scratch_mount
+
+mkdir -p $SCRATCH_MNT/a/b
+mkdir $SCRATCH_MNT/0
+mkdir $SCRATCH_MNT/1
+mkdir $SCRATCH_MNT/a/b/c
+mv $SCRATCH_MNT/0 $SCRATCH_MNT/a/b/c
+mv $SCRATCH_MNT/1 $SCRATCH_MNT/a/b/c
+echo 'ola mundo' $SCRATCH_MNT/a/b/c/foo.txt
+mkdir $SCRATCH_MNT/a/b/c/x
+mkdir $SCRATCH_MNT/a/b/c/x2
+mkdir $SCRATCH_MNT/a/b/y
+mkdir $SCRATCH_MNT/a/b/z
+mkdir -p $SCRATCH_MNT/a/b/d1/d2/d3
+mkdir $SCRATCH_MNT/a/b/d4
+
+# Filesystem looks like:
+#
+# .(ino 256)
+# |-- a/ (ino 257)
+# |-- b/ (ino 258)
+# |-- c/ (ino 261)
+# | |-- foo.txt (ino 262)
+# | |-- 0/ (ino 259)
+# | |-- 1/ (ino 260)
+# | |-- x/ (ino 263)
+# | |-- x2/ (ino 264)
+# |
+# |-- y/ (ino 265)
+# |-- z/ (ino 266)
+# |-- d1/ (ino 267)
+# | |-- d2/ (ino 268)
+# | |-- d3/ (ino 269)
+# |
+# |-- d4/ (ino 270)
+
+_run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/mysnap1
+
+rm -f $SCRATCH_MNT/a/b/c/foo.txt
+mv $SCRATCH_MNT/a/b/y $SCRATCH_MNT/a/b/YY
+mv $SCRATCH_MNT/a/b/z $SCRATCH_MNT/a
+mv $SCRATCH_MNT/a/b/c/x $SCRATCH_MNT/a/b/YY
+mv $SCRATCH_MNT/a/b/c/0 $SCRATCH_MNT/a/b/YY/00
+mv $SCRATCH_MNT/a/b/c/x2 $SCRATCH_MNT/a/z/X_2
+mv $SCRATCH_MNT/a/b/c/1 $SCRATCH_MNT/a/z/X_2
+rmdir $SCRATCH_MNT/a/b/c
+mv $SCRATCH_MNT/a/b/d4 $SCRATCH_MNT/a/d44
+mv $SCRATCH_MNT/a/b/d1/d2 $SCRATCH_MNT/a/d44
+rmdir $SCRATCH_MNT/a/b/d1
+
+# Filesystem now looks like:
+#
+# .(ino 256)
+# |-- a/ (ino 257)
+# |-- b/ (ino 258)
+# | |-- YY/ (ino 265)
+# ||-- x/ (ino 263)
+# ||-- 00/ (ino 259)
+# |
+# |-- z/ (ino 266)
+# | |-- X_2/ (ino 264)
+# ||-- 1/ (ino 260)
+# |
+# |-- d44/ (ino 270)
+# |-- d2/ (ino 268)
+# |-- d3/ (ino 269)
+
+_run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/mysnap2
+
+run_check $FSSUM_PROG -A -f -w $tmp/1.fssum $SCRATCH_MNT/mysnap1
+run_check
[PATCH v2] xfstests: add test btrfs/042 for btrfs incremental send
Regression test for a btrfs incremental send issue where invalid paths for
utimes, chown and chmod operations were sent to the send stream, causing
btrfs receive to fail.
If a directory had a move/rename operation delayed, and none of its parent
directories, except for the immediate one, had delayed move/rename operations,
after processing the directory's references, the incremental send code would
issue invalid paths for utimes, chown and chmod operations.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: fix send issuing outdated paths for utimes, chown and chmod
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
V2: Some cleanup as suggested by Dave Chinner. Use _check_scratch_fs() and
removed redundant stderr redirection when calling fssum via run_check.
tests/btrfs/042 | 132 +++
tests/btrfs/042.out |1 +
tests/btrfs/group |1 +
3 files changed, 134 insertions(+)
create mode 100755 tests/btrfs/042
create mode 100644 tests/btrfs/042.out
diff --git a/tests/btrfs/042 b/tests/btrfs/042
new file mode 100755
index 000..2bd5147
--- /dev/null
+++ b/tests/btrfs/042
@@ -0,0 +1,132 @@
+#! /bin/bash
+# FS QA Test No. btrfs/042
+#
+# Regression test for a btrfs incremental send issue where under certain
+# scenarios invalid paths for utimes, chown and chmod operations were sent
+# to the send stream, causing btrfs receive to fail.
+#
+# If a directory had a move/rename operation delayed, and none of its parent
+# directories, except for the immediate one, had delayed move/rename
operations,
+# after processing the directory's references, the incremental send code would
+# issue invalid paths for utimes, chown and chmod operations.
+#
+# This issue is fixed by the following linux kernel btrfs patch:
+#
+# Btrfs: fix send issuing outdated paths for utimes, chown and chmod
+#
+#---
+# Copyright (c) 2014 Filipe Manana. 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
+#---
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo QA output created by $seq
+
+here=`pwd`
+tmp=`mktemp -d`
+status=1 # failure is the default!
+trap _cleanup; exit \$status 0 1 2 3 15
+
+_cleanup()
+{
+rm -fr $tmp
+}
+
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+
+# real QA test starts here
+_supported_fs btrfs
+_supported_os Linux
+_require_scratch
+_need_to_be_root
+
+FSSUM_PROG=$here/src/fssum
+[ -x $FSSUM_PROG ] || _notrun fssum not built
+
+rm -f $seqres.full
+
+_scratch_mkfs /dev/null 21
+_scratch_mount
+
+umask 0
+mkdir -p $SCRATCH_MNT/a/b/c/d/e
+mkdir $SCRATCH_MNT/a/b/c/f
+echo 'ola ' $SCRATCH_MNT/a/b/c/d/e/file.txt
+chmod 0777 $SCRATCH_MNT/a/b/c/d/e
+
+# Filesystem looks like:
+#
+# . (ino 256)
+# |-- a/ (ino 257)
+# |-- b/ (ino 258)
+# |-- c/ (ino 259)
+# |-- d/ (ino 260)
+# | |-- e/ (ino 261)
+# | |-- file.txt(ino 262)
+# |
+# |-- f/ (ino 263)
+
+_run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/mysnap1
+
+echo 'mundo' $SCRATCH_MNT/a/b/c/d/e/file.txt
+mv $SCRATCH_MNT/a/b/c/d/e/file.txt $SCRATCH_MNT/a/b/c/d/e/file2.txt
+mv $SCRATCH_MNT/a/b/c/f $SCRATCH_MNT/a/b/f2
+mv $SCRATCH_MNT/a/b/c/d/e $SCRATCH_MNT/a/b/f2/e2
+mv $SCRATCH_MNT/a/b/c $SCRATCH_MNT/a/b/c2
+mv $SCRATCH_MNT/a/b/c2/d $SCRATCH_MNT/a/b/c2/d2
+chmod 0700 $SCRATCH_MNT/a/b/f2/e2
+
+# Filesystem now looks like:
+#
+# . (ino 256)
+# |-- a/ (ino 257)
+# |-- b/ (ino 258)
+# |-- c2/(ino 259)
+# | |-- d2/(ino 260)
+# |
+# |-- f2/(ino 263)
+# |-- e2 (ino 261)
+# |-- file2.txt (ino 263)
+
+_run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/mysnap2
+
+run_check $FSSUM_PROG -A -f -w $tmp/1.fssum $SCRATCH_MNT/mysnap1
+run_check $FSSUM_PROG -A -f -w $tmp/2.fssum -x $SCRATCH_MNT/mysnap2/mysnap1 \
+
[PATCH] xfstests: add function _require_fssum()
To avoid repeating detection of fssum presence in many btrfs tests, as
suggested by Dave Chinner.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
common/rc |7 +++
tests/btrfs/007 |5 +
tests/btrfs/016 |5 +
tests/btrfs/030 |5 +
tests/btrfs/038 |5 +
tests/btrfs/039 |5 +
tests/btrfs/040 |5 +
tests/btrfs/041 |5 +
tests/btrfs/042 |5 +
9 files changed, 15 insertions(+), 32 deletions(-)
mode change 100644 = 100755 tests/btrfs/016
diff --git a/common/rc b/common/rc
index 5df504c..cce05cc 100644
--- a/common/rc
+++ b/common/rc
@@ -2144,6 +2144,13 @@ _require_cp_reflink()
_notrun This test requires a cp with --reflink support.
}
+_require_fssum()
+{
+ HERE=`pwd`
+ FSSUM_PROG=$HERE/src/fssum
+ [ -x $FSSUM_PROG ] || _notrun fssum not built
+}
+
# Given 2 files, verify that they have the same mapping but different
# inodes - i.e. an undisturbed reflink
# Silent if so, make noise if not
diff --git a/tests/btrfs/007 b/tests/btrfs/007
index 5df9ccb..5430613 100755
--- a/tests/btrfs/007
+++ b/tests/btrfs/007
@@ -31,7 +31,6 @@ seq=`basename $0`
seqres=$RESULT_DIR/$seq
echo QA output created by $seq
-here=`pwd`
tmp=`mktemp -d`
status=1
@@ -52,11 +51,9 @@ _need_to_be_root
_supported_fs btrfs
_supported_os Linux
_require_scratch
+_require_fssum
_require_seek_data_hole
-FSSUM_PROG=$here/src/fssum
-[ -x $FSSUM_PROG ] || _notrun fssum not built
-
rm -f $seqres.full
workout()
diff --git a/tests/btrfs/016 b/tests/btrfs/016
old mode 100644
new mode 100755
index 6faead1..d04c21a
--- a/tests/btrfs/016
+++ b/tests/btrfs/016
@@ -26,7 +26,6 @@ seq=`basename $0`
seqres=$RESULT_DIR/$seq
echo QA output created by $seq
-here=`pwd`
tmp=`mktemp -d`
tmp_dir=send_temp_$seq
@@ -51,9 +50,7 @@ trap _cleanup ; exit \$status 0 1 2 3 15
_supported_fs btrfs
_supported_os Linux
_require_scratch
-
-FSSUM_PROG=$here/src/fssum
-[ -x $FSSUM_PROG ] || _notrun fssum not built
+_require_fssum
_scratch_mkfs /dev/null 21
diff --git a/tests/btrfs/030 b/tests/btrfs/030
index a9f5fb4..a76a410 100755
--- a/tests/btrfs/030
+++ b/tests/btrfs/030
@@ -36,7 +36,6 @@ seq=`basename $0`
seqres=$RESULT_DIR/$seq
echo QA output created by $seq
-here=`pwd`
tmp=`mktemp -d`
status=1 # failure is the default!
trap _cleanup; exit \$status 0 1 2 3 15
@@ -54,11 +53,9 @@ _cleanup()
_supported_fs btrfs
_supported_os Linux
_require_scratch
+_require_fssum
_need_to_be_root
-FSSUM_PROG=$here/src/fssum
-[ -x $FSSUM_PROG ] || _notrun fssum not built
-
rm -f $seqres.full
_scratch_mkfs /dev/null 21
diff --git a/tests/btrfs/038 b/tests/btrfs/038
index 8893696..4941d3e 100755
--- a/tests/btrfs/038
+++ b/tests/btrfs/038
@@ -32,7 +32,6 @@ seq=`basename $0`
seqres=$RESULT_DIR/$seq
echo QA output created by $seq
-here=`pwd`
tmp=`mktemp -d`
status=1 # failure is the default!
trap _cleanup; exit \$status 0 1 2 3 15
@@ -50,11 +49,9 @@ _cleanup()
_supported_fs btrfs
_supported_os Linux
_require_scratch
+_require_fssum
_need_to_be_root
-FSSUM_PROG=$here/src/fssum
-[ -x $FSSUM_PROG ] || _notrun fssum not built
-
rm -f $seqres.full
_scratch_mkfs /dev/null 21
diff --git a/tests/btrfs/039 b/tests/btrfs/039
index 41e09be..758b23c 100755
--- a/tests/btrfs/039
+++ b/tests/btrfs/039
@@ -35,7 +35,6 @@ seq=`basename $0`
seqres=$RESULT_DIR/$seq
echo QA output created by $seq
-here=`pwd`
tmp=`mktemp -d`
status=1 # failure is the default!
trap _cleanup; exit \$status 0 1 2 3 15
@@ -53,11 +52,9 @@ _cleanup()
_supported_fs btrfs
_supported_os Linux
_require_scratch
+_require_fssum
_need_to_be_root
-FSSUM_PROG=$here/src/fssum
-[ -x $FSSUM_PROG ] || _notrun fssum not built
-
rm -f $seqres.full
_scratch_mkfs /dev/null 21
diff --git a/tests/btrfs/040 b/tests/btrfs/040
index 77c4a84..dfd495c 100755
--- a/tests/btrfs/040
+++ b/tests/btrfs/040
@@ -35,7 +35,6 @@ seq=`basename $0`
seqres=$RESULT_DIR/$seq
echo QA output created by $seq
-here=`pwd`
tmp=`mktemp -d`
status=1 # failure is the default!
trap _cleanup; exit \$status 0 1 2 3 15
@@ -53,11 +52,9 @@ _cleanup()
_supported_fs btrfs
_supported_os Linux
_require_scratch
+_require_fssum
_need_to_be_root
-FSSUM_PROG=$here/src/fssum
-[ -x $FSSUM_PROG ] || _notrun fssum not built
-
rm -f $seqres.full
_scratch_mkfs /dev/null 21
diff --git a/tests/btrfs/041 b/tests/btrfs/041
index bfc0e4b..a960001 100755
--- a/tests/btrfs/041
+++ b/tests/btrfs/041
@@ -31,7 +31,6 @@ seq=`basename $0`
seqres=$RESULT_DIR/$seq
echo QA output created by $seq
-here=`pwd`
tmp=`mktemp -d`
status=1 # failure is the default!
trap _cleanup; exit \$status 0 1 2 3 15
@@ -49,11 +48,9 @@ _cleanup()
_supported_fs btrfs
_supported_os Linux
_require_scratch
+_require_fssum
_need_to_be_root
-FSSUM_PROG=$here/src/fssum
-[ -x $FSSUM_PROG ] || _notrun fssum not built
-
rm -f $seqres.full
_scratch_mkfs /dev/null 21
diff --git
Re: [PATCH] xfstests: add test for btrfs send issuing premature rmdir operations
On Mon, Feb 24, 2014 at 5:25 AM, Dave Chinner da...@fromorbit.com wrote:
On Wed, Feb 19, 2014 at 02:32:32PM +, Filipe David Borba Manana wrote:
Regression test for btrfs incremental send issue where a rmdir instruction
is sent against an orphan directory inode which is not empty yet, causing
btrfs receive to fail when it attempts to remove the directory.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: fix send attempting to rmdir non-empty directories
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
tests/btrfs/041 | 153
+++
tests/btrfs/041.out |1 +
tests/btrfs/group |1 +
3 files changed, 155 insertions(+)
create mode 100755 tests/btrfs/041
create mode 100644 tests/btrfs/041.out
diff --git a/tests/btrfs/041 b/tests/btrfs/041
new file mode 100755
index 000..9de9326
--- /dev/null
+++ b/tests/btrfs/041
@@ -0,0 +1,153 @@
+#! /bin/bash
+# FS QA Test No. btrfs/041
+#
+# Regression test for btrfs incremental send issue where a rmdir instruction
+# is sent against an orphan directory inode which is not empty yet, causing
+# btrfs receive to fail when it attempts to remove the directory.
+#
+# This issue is fixed by the following linux kernel btrfs patch:
+#
+# Btrfs: fix send attempting to rmdir non-empty directories
+#
+#---
+# Copyright (c) 2014 Filipe Manana. 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
+#---
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo QA output created by $seq
+
+here=`pwd`
+tmp=`mktemp -d`
+status=1 # failure is the default!
+trap _cleanup; exit \$status 0 1 2 3 15
+
+_cleanup()
+{
+rm -fr $tmp
+}
+
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+
+# real QA test starts here
+_supported_fs btrfs
+_supported_os Linux
+_require_scratch
+_need_to_be_root
+
+FSSUM_PROG=$here/src/fssum
+[ -x $FSSUM_PROG ] || _notrun fssum not built
This is duplicated across several tests now. Perhaps this should be
factored now into a _requires_fssum helper (separate patch is
fine)?
+
+_scratch_unmount
+_check_btrfs_filesystem $SCRATCH_DEV
you should be able to use _check_scratch_fs() here. I note that the
btrfs path does not unmount the scratch device, so you should update
it to do so (like _check_xfs_filesytem does) and then
_check_scratch_fs() will just Do The Right Thing.
+_scratch_mkfs /dev/null 21
+_scratch_mount
+
+_run_btrfs_util_prog receive $SCRATCH_MNT -f $tmp/1.snap
+run_check $FSSUM_PROG -r $tmp/1.fssum $SCRATCH_MNT/mysnap1 2 $seqres.full
+
+_run_btrfs_util_prog receive $SCRATCH_MNT -f $tmp/2.snap
+run_check $FSSUM_PROG -r $tmp/2.fssum $SCRATCH_MNT/mysnap2 2 $seqres.full
Hasn't run_check already redirected everything to $seqres.full?
+_scratch_unmount
+_check_btrfs_filesystem $SCRATCH_DEV
_check_scratch_fs() here too.
Cheers,
All done in V2 (same for the other test).
For the require_fssum() function, I made a patch on top of these 2 so
that it updates all existing btrfs tests that need fssum ([PATCH]
xfstests: add function _require_fssum()).
Thanks for the good suggestions Dave.
Dave.
--
Dave Chinner
da...@fromorbit.com
--
Filipe David Manana,
Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men.
--
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] Btrfs: more efficient split extent state insertion
When we split an extent state there's no need to start the rbtree search
from the root node - we can start it from the original extent state node,
since we would end up in its subtree if we do the search starting at the
root node anyway.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
V2: Made the intention more clear, that it works only if the tree is not
empty (which is always the case when spliting extent states).
fs/btrfs/extent_io.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index fbe501d..eb465e9 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -229,12 +229,14 @@ void free_extent_state(struct extent_state *state)
}
}
-static struct rb_node *tree_insert(struct rb_root *root, u64 offset,
+static struct rb_node *tree_insert(struct rb_root *root,
+ struct rb_node *search_start,
+ u64 offset,
struct rb_node *node,
struct rb_node ***p_in,
struct rb_node **parent_in)
{
- struct rb_node **p = root-rb_node;
+ struct rb_node **p;
struct rb_node *parent = NULL;
struct tree_entry *entry;
@@ -244,6 +246,7 @@ static struct rb_node *tree_insert(struct rb_root *root,
u64 offset,
goto do_insert;
}
+ p = search_start ? search_start : root-rb_node;
while (*p) {
parent = *p;
entry = rb_entry(parent, struct tree_entry, rb_node);
@@ -430,7 +433,7 @@ static int insert_state(struct extent_io_tree *tree,
set_state_bits(tree, state, bits);
- node = tree_insert(tree-state, end, state-rb_node, p, parent);
+ node = tree_insert(tree-state, NULL, end, state-rb_node, p, parent);
if (node) {
struct extent_state *found;
found = rb_entry(node, struct extent_state, rb_node);
@@ -477,8 +480,8 @@ static int split_state(struct extent_io_tree *tree, struct
extent_state *orig,
prealloc-state = orig-state;
orig-start = split;
- node = tree_insert(tree-state, prealloc-end, prealloc-rb_node,
- NULL, NULL);
+ node = tree_insert(tree-state, orig-rb_node, prealloc-end,
+ prealloc-rb_node, NULL, NULL);
if (node) {
free_extent_state(prealloc);
return -EEXIST;
--
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
[PATCH] Btrfs-progs: fsck: fix wrong return value in check_block()
We found btrfsck will output backrefs mismatch while the filesystem is defenitely ok. The problem is that check_block() don't return right value,which makes btrfsck won't walk all tree blocks thus we don't get a consistent filesystem, we will fail to check extent refs etc. Reported-by: Gui Hecheng guihc.f...@cn.fujitsu.com Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com --- cmds-check.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmds-check.c b/cmds-check.c index a2afae6..253569f 100644 --- a/cmds-check.c +++ b/cmds-check.c @@ -2477,7 +2477,7 @@ static int check_block(struct btrfs_trans_handle *trans, struct cache_extent *cache; struct btrfs_key key; enum btrfs_tree_block_status status; - int ret = 1; + int ret = 0; int level; cache = lookup_cache_extent(extent_cache, buf-start, buf-len); -- 1.9.0 -- 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] xfstests: add function _require_fssum()
On Mon, Feb 24, 2014 at 11:56:23AM +, Filipe David Borba Manana wrote:
To avoid repeating detection of fssum presence in many btrfs tests, as
suggested by Dave Chinner.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
common/rc |7 +++
tests/btrfs/007 |5 +
tests/btrfs/016 |5 +
tests/btrfs/030 |5 +
tests/btrfs/038 |5 +
tests/btrfs/039 |5 +
tests/btrfs/040 |5 +
tests/btrfs/041 |5 +
tests/btrfs/042 |5 +
9 files changed, 15 insertions(+), 32 deletions(-)
mode change 100644 = 100755 tests/btrfs/016
diff --git a/common/rc b/common/rc
index 5df504c..cce05cc 100644
--- a/common/rc
+++ b/common/rc
@@ -2144,6 +2144,13 @@ _require_cp_reflink()
_notrun This test requires a cp with --reflink support.
}
+_require_fssum()
+{
+ HERE=`pwd`
+ FSSUM_PROG=$HERE/src/fssum
+ [ -x $FSSUM_PROG ] || _notrun fssum not built
+}
$here is defined by check to be the root of the xfstests instance
that is running. There's 60+ tests that already us it. Hence:
_require_fssum()
{
FSSUM_PROG=$here/src/fssum
[ -x $FSSUM_PROG ] || _notrun fssum not built
}
Is all you need here.
+
# Given 2 files, verify that they have the same mapping but different
# inodes - i.e. an undisturbed reflink
# Silent if so, make noise if not
diff --git a/tests/btrfs/007 b/tests/btrfs/007
index 5df9ccb..5430613 100755
--- a/tests/btrfs/007
+++ b/tests/btrfs/007
@@ -31,7 +31,6 @@ seq=`basename $0`
seqres=$RESULT_DIR/$seq
echo QA output created by $seq
-here=`pwd`
tmp=`mktemp -d`
status=1
Yeah, redefining $here is a bad thing to do :/
And I'd missed that this was being done in all the new btrfs tests,
otherwise I would have pulled it up earlier.
It also points out that the btrfs tests are using a non-standard
$tmp directory - one that is in the xfstests source directory.
That's a bad thing, too - tests should be using:
tmp=/tmp/$$
to store small temporary files.
If /tmp is too small for what a test needs, then the test should be
using $TEST_DIR as the store for the temporary files to exercise
the filesystem under test as much as possible. e.g. send image
files build form snapshots of SCRATCH_DEV should be stored on TEST_DIR,
not in $tmp; filesystem image files that are mounted by loopback
should be stored on TEST_DIR or SCRATCH_MNT, not $tmp. And so on.
i.e. the idea is that you direct as much of the IO to the test_DIR
and SCRATCH_MNT as possible, not to the filesystem that is hosting
$tmp or the xfstests source directory
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: [PATCH] xfstests: add function _require_fssum()
On Mon, Feb 24, 2014 at 12:23 PM, Dave Chinner da...@fromorbit.com wrote:
On Mon, Feb 24, 2014 at 11:56:23AM +, Filipe David Borba Manana wrote:
To avoid repeating detection of fssum presence in many btrfs tests, as
suggested by Dave Chinner.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
common/rc |7 +++
tests/btrfs/007 |5 +
tests/btrfs/016 |5 +
tests/btrfs/030 |5 +
tests/btrfs/038 |5 +
tests/btrfs/039 |5 +
tests/btrfs/040 |5 +
tests/btrfs/041 |5 +
tests/btrfs/042 |5 +
9 files changed, 15 insertions(+), 32 deletions(-)
mode change 100644 = 100755 tests/btrfs/016
diff --git a/common/rc b/common/rc
index 5df504c..cce05cc 100644
--- a/common/rc
+++ b/common/rc
@@ -2144,6 +2144,13 @@ _require_cp_reflink()
_notrun This test requires a cp with --reflink support.
}
+_require_fssum()
+{
+ HERE=`pwd`
+ FSSUM_PROG=$HERE/src/fssum
+ [ -x $FSSUM_PROG ] || _notrun fssum not built
+}
$here is defined by check to be the root of the xfstests instance
that is running. There's 60+ tests that already us it. Hence:
_require_fssum()
{
FSSUM_PROG=$here/src/fssum
[ -x $FSSUM_PROG ] || _notrun fssum not built
}
Is all you need here.
Hum, doesn't work unless the test file defines $here. At least when
running a single only (.e.g. ./check btrfs/041).
+
# Given 2 files, verify that they have the same mapping but different
# inodes - i.e. an undisturbed reflink
# Silent if so, make noise if not
diff --git a/tests/btrfs/007 b/tests/btrfs/007
index 5df9ccb..5430613 100755
--- a/tests/btrfs/007
+++ b/tests/btrfs/007
@@ -31,7 +31,6 @@ seq=`basename $0`
seqres=$RESULT_DIR/$seq
echo QA output created by $seq
-here=`pwd`
tmp=`mktemp -d`
status=1
Yeah, redefining $here is a bad thing to do :/
See above :)
And I'd missed that this was being done in all the new btrfs tests,
otherwise I would have pulled it up earlier.
It also points out that the btrfs tests are using a non-standard
$tmp directory - one that is in the xfstests source directory.
That's a bad thing, too - tests should be using:
tmp=/tmp/$$
to store small temporary files.
If /tmp is too small for what a test needs, then the test should be
using $TEST_DIR as the store for the temporary files to exercise
the filesystem under test as much as possible. e.g. send image
files build form snapshots of SCRATCH_DEV should be stored on TEST_DIR,
not in $tmp; filesystem image files that are mounted by loopback
should be stored on TEST_DIR or SCRATCH_MNT, not $tmp. And so on.
i.e. the idea is that you direct as much of the IO to the test_DIR
and SCRATCH_MNT as possible, not to the filesystem that is hosting
$tmp or the xfstests source directory
Right. Sounds like a separate patch (to use TEST_DIR/$$ for e.g. as a
place to store temporary test data).
Thanks Dave
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
Filipe David Manana,
Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men.
--
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] btrfs: Allow forced conversion of metadata to dup profile on multiple devices
On Thu, Feb 20, 2014 at 6:57 PM, David Sterba dste...@suse.cz wrote: On Wed, Feb 19, 2014 at 11:10:41AM -0500, Austin S Hemmelgarn wrote: Currently, btrfs balance start fails when trying to convert metadata or system chunks to dup profile on filesystems with multiple devices. This requires that a conversion from a multi-device filesystem to a single device filesystem use the following methodology: 1. btrfs balance start -dconvert=single -mconvert=single \ -sconvert=single -f / 2. btrfs device delete / /dev/sdx 3. btrfs balance start -mconvert=dup -sconvert=dup / This results in a period of time (possibly very long if the devices are big) where you don't have the protection guarantees of multiple copies of metadata chunks. After applying this patch, one can instead use the following methodology for conversion from a multi-device filesystem to a single device filesystem: 1. btrfs balance start -dconvert=single -mconvert=dup \ -sconvert=dup -f / 2. btrfs device delete / /dev/sdx This greatly reduces the chances of the operation causing data loss due to a read error during the device delete. Signed-off-by: Austin S. Hemmelgarn ahferro...@gmail.com Reviewed-by: David Sterba dste...@suse.cz Sounds useful. The muliple devices + DUP is allowed setup when the device is added, this patch only adds the 'delete' counterpart. The imroved data loss protection during the process is a good thing. Hi, Have you actually tried to queue it? Unless I'm missing something, it won't compile, and on top of that, it seems to be corrupted too.. IIRC muliple devices + DUP is allowed only until the first balance, has that changed? Thanks, Ilya -- 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] btrfs: Allow forced conversion of metadata to dup profile on multiple devices
On 2014-02-24 08:37, Ilya Dryomov wrote: On Thu, Feb 20, 2014 at 6:57 PM, David Sterba dste...@suse.cz wrote: On Wed, Feb 19, 2014 at 11:10:41AM -0500, Austin S Hemmelgarn wrote: Currently, btrfs balance start fails when trying to convert metadata or system chunks to dup profile on filesystems with multiple devices. This requires that a conversion from a multi-device filesystem to a single device filesystem use the following methodology: 1. btrfs balance start -dconvert=single -mconvert=single \ -sconvert=single -f / 2. btrfs device delete / /dev/sdx 3. btrfs balance start -mconvert=dup -sconvert=dup / This results in a period of time (possibly very long if the devices are big) where you don't have the protection guarantees of multiple copies of metadata chunks. After applying this patch, one can instead use the following methodology for conversion from a multi-device filesystem to a single device filesystem: 1. btrfs balance start -dconvert=single -mconvert=dup \ -sconvert=dup -f / 2. btrfs device delete / /dev/sdx This greatly reduces the chances of the operation causing data loss due to a read error during the device delete. Signed-off-by: Austin S. Hemmelgarn ahferro...@gmail.com Reviewed-by: David Sterba dste...@suse.cz Sounds useful. The muliple devices + DUP is allowed setup when the device is added, this patch only adds the 'delete' counterpart. The imroved data loss protection during the process is a good thing. Hi, Have you actually tried to queue it? Unless I'm missing something, it won't compile, and on top of that, it seems to be corrupted too.. The patch itself was made using git, AFAICT it should be fine. I've personally built and tested it using UML. IIRC muliple devices + DUP is allowed only until the first balance, has that changed? This is just a limitation of how the kernel handles balances, DUP profiles with multiple devices work, it's just terribly inefficient. The primary use case is converting a multi-device FS with RAID for metadata to a single device FS without having to reduce integrity. Thanks, Ilya -- 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: kernel BUG at fs/btrfs/ctree.c:3215!
FYI, this crash was reproducible and was happening when using rsync with --inplace option on a fragmented file: # filefrag * bayes_journal: 2 extents found bayes_seen: 988 extents found bayes_toks: 41 extents found rsync process was hanging here: var/lib/amavis/.spamassassin/ var/lib/amavis/.spamassassin/bayes_journal (no more entries after that) Mount option contains autodefrag; there were arond 20 snapshots of that subvolume present. After removing the fragmented file, it doesn't crash anymore. The size of the file was around 80 MB. Unfortunately I didn't check if the issue shows up with autodefrag mount option disabled. -- Tomasz Chmielewski http://wpkg.org On Sun, 23 Feb 2014 12:25:28 +0100 Tomasz Chmielewski t...@virtall.com wrote: Got this with 3.14-rc3: [525983.966567] [ cut here ] [525983.966645] kernel BUG at fs/btrfs/ctree.c:3215! [525983.966705] invalid opcode: [#1] SMP [525983.966765] Modules linked in: ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables cpufreq_ondemand cpufreq_conservative cpufreq_powersave cpufreq_stats bridge stp llc ipv6 btrfs xor raid6_pq zlib_deflate loop parport_pc parport battery button video tpm_infineon tpm_tis tpm ehci_pci pcspkr acpi_cpufreq ehci_hcd i2c_i801 i2c_core lpc_ich mfd_core ext4 crc16 jbd2 mbcache raid1 sg sd_mod ahci libahci libata scsi_mod r8169 mii [525983.967240] CPU: 4 PID: 15321 Comm: btrfs-endio-wri Not tainted 3.14.0-rc3 #1 [525983.967351] Hardware name: System manufacturer System Product Name/P8H77-M PRO, BIOS 1101 02/04/2013 [525983.967465] task: 8807f12a ti: 8805eb9f8000 task.ti: 8805eb9f8000 [525983.967576] RIP: 0010:[a02a8361] [a02a8361] btrfs_set_item_key_safe+0xb2/0x119 [btrfs] [525983.967706] RSP: 0018:8805eb9f9b18 EFLAGS: 00010286 [525983.967766] RAX: RBX: 000a RCX: [525983.967877] RDX: 033c9000 RSI: 8805eb9f9c4f RDI: 8805eb9f9af7 [525983.967987] RBP: 8805eb9f9b68 R08: 8805eb9f9b38 R09: 88047c1ccc08 [525983.968098] R10: 1000 R11: 1600 R12: 88047c1ccb40 [525983.968209] R13: 8807e7c76360 R14: 8802a351a000 R15: 8805eb9f9c4f [525983.968321] FS: () GS:88081fb0() knlGS: [525983.968434] CS: 0010 DS: ES: CR0: 80050033 [525983.968494] CR2: 040f9fe8 CR3: 0160b000 CR4: 001407e0 [525983.968604] Stack: [525983.968657] 2600 6c00030f 033c5000 [525983.968773] 00030f26 8807e7c76360 88047c1ccb40 033e [525983.96] 8805eb9f9ca8 a02d589d [525983.969003] Call Trace: [525983.969076] [a02d589d] __btrfs_drop_extents+0x6c1/0xb12 [btrfs] [525983.969155] [a02c9811] insert_reserved_file_extent.constprop.63+0x9a/0x2a5 [btrfs] [525983.969281] [a02ccebb] btrfs_finish_ordered_io+0x265/0x3ef [btrfs] [525983.969403] [a02cd055] finish_ordered_fn+0x10/0x12 [btrfs] [525983.969481] [a02eb649] worker_loop+0x15e/0x495 [btrfs] [525983.969556] [a02eb4eb] ? btrfs_queue_worker+0x269/0x269 [btrfs] [525983.969623] [81050c76] kthread+0xcd/0xd5 [525983.969685] [81050ba9] ? kthread_freezable_should_stop+0x43/0x43 [525983.969749] [81398a7c] ret_from_fork+0x7c/0xb0 [525983.969811] [81050ba9] ? kthread_freezable_should_stop+0x43/0x43 [525983.969873] Code: 8d 75 bf b9 11 00 00 00 4c 89 e7 48 63 d2 48 6b d2 19 48 83 c2 65 e8 b0 89 03 00 48 8d 7d bf 4c 89 fe e8 9e f5 ff ff 85 c0 7f 02 0f 0b 49 8b 47 09 48 63 d3 48 8d 75 bf 48 6b d2 19 b9 11 00 00 [525983.970116] RIP [a02a8361] btrfs_set_item_key_safe+0xb2/0x119 [btrfs] [525983.970237] RSP 8805eb9f9b18 [525983.970581] ---[ end trace 40b604c8c92dba0d ]--- -- 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
How to identify if a partition containing a btrfs volume is mounted and where
Hi, I am trying to enhance GParted (http://www.gparted.org/) to better support btrfs, specifically multi-device ones. GParted displays the busy status (mounted or not) and the mount point of each partition. For a single device file system this is easy. Entry in /proc/mounts for the partition identifies it's mounted and provides the mount point. In the general case for btrfs I don't know how to get from device name containing a btrfs volume to knowing if it's mounted and where? btrfs filesystem show can identify the devices in a btrfs, but if the mounting device was removed from the file system this linkage is broken. # mkfs.btrfs /dev/sdb2 /dev/sdb3 /dev/sdb4 # mount /dev/sdb2 /mnt/1 # btrfs device delete /dev/sdb2 /mnt/1 So /dev/sdb2 is no longer part of the file system, but it's still mounted using it. # grep btrfs /proc/mounts /dev/sdb2 /mnt/1 btrfs rw,seclabel,relatime,ssd,space_cache 0 0 # btrfs filesystem show /dev/sdb3 Label: none uuid: d1e98472-e562-466c-8fa4-ddcaee757c20 Total devices 2 FS bytes used 156.00KB devid3 size 2.00GB used 961.56MB path /dev/sdb4 devid2 size 2.00GB used 552.00MB path /dev/sdb3 So in there a way to determine whether a specific partition containing a btrfs volume is mounted and on what mount point? Thanks, Mike -- 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: How to identify if a partition containing a btrfs volume is mounted and where
On Mon, Feb 24, 2014 at 01:48:55PM +, Mike Fleetwood wrote: Hi, I am trying to enhance GParted (http://www.gparted.org/) to better support btrfs, specifically multi-device ones. GParted displays the busy status (mounted or not) and the mount point of each partition. For a single device file system this is easy. Entry in /proc/mounts for the partition identifies it's mounted and provides the mount point. In the general case for btrfs I don't know how to get from device name containing a btrfs volume to knowing if it's mounted and where? btrfs filesystem show can identify the devices in a btrfs, but if the mounting device was removed from the file system this linkage is broken. [snip] So in there a way to determine whether a specific partition containing a btrfs volume is mounted and on what mount point? Right now: no. Anand posted some kernel patches for an ioctl a few weeks ago that would allow you to get hold of the kernel's UUID-device mapping. There was also a suggestion that the information also be exposed in /sys/fs/btrfs, and that mounted filesystems, and their list of devices, be shown in /sys as well. See the discussion from [1] onwards. Hugo. [1] http://www.spinics.net/lists/linux-btrfs/msg31080.html -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- There are three mistaikes in this sentance. --- signature.asc Description: Digital signature
Re: [PATCH] btrfs: Allow forced conversion of metadata to dup profile on multiple devices
On Mon, Feb 24, 2014 at 3:44 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 2014-02-24 08:37, Ilya Dryomov wrote:
On Thu, Feb 20, 2014 at 6:57 PM, David Sterba dste...@suse.cz wrote:
On Wed, Feb 19, 2014 at 11:10:41AM -0500, Austin S Hemmelgarn wrote:
Currently, btrfs balance start fails when trying to convert metadata or
system chunks to dup profile on filesystems with multiple devices. This
requires that a conversion from a multi-device filesystem to a single
device filesystem use the following methodology:
1. btrfs balance start -dconvert=single -mconvert=single \
-sconvert=single -f /
2. btrfs device delete / /dev/sdx
3. btrfs balance start -mconvert=dup -sconvert=dup /
This results in a period of time (possibly very long if the devices are
big) where you don't have the protection guarantees of multiple copies
of metadata chunks.
After applying this patch, one can instead use the following methodology
for conversion from a multi-device filesystem to a single device
filesystem:
1. btrfs balance start -dconvert=single -mconvert=dup \
-sconvert=dup -f /
2. btrfs device delete / /dev/sdx
This greatly reduces the chances of the operation causing data loss due
to a read error during the device delete.
Signed-off-by: Austin S. Hemmelgarn ahferro...@gmail.com
Reviewed-by: David Sterba dste...@suse.cz
Sounds useful. The muliple devices + DUP is allowed setup when the
device is added, this patch only adds the 'delete' counterpart. The
imroved data loss protection during the process is a good thing.
Hi,
Have you actually tried to queue it? Unless I'm missing something, it won't
compile, and on top of that, it seems to be corrupted too..
The patch itself was made using git, AFAICT it should be fine. I've
personally built and tested it using UML.
It doesn't look fine. It was generated with git, but it got corrupted
on the way: either how you pasted it or the email client you use is the
problem.
On Wed, Feb 19, 2014 at 6:10 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
Currently, btrfs balance start fails when trying to convert metadata or
system chunks to dup profile on filesystems with multiple devices. This
requires that a conversion from a multi-device filesystem to a single
device filesystem use the following methodology:
1. btrfs balance start -dconvert=single -mconvert=single \
-sconvert=single -f /
2. btrfs device delete / /dev/sdx
3. btrfs balance start -mconvert=dup -sconvert=dup /
This results in a period of time (possibly very long if the devices are
big) where you don't have the protection guarantees of multiple copies
of metadata chunks.
After applying this patch, one can instead use the following methodology
for conversion from a multi-device filesystem to a single device
filesystem:
1. btrfs balance start -dconvert=single -mconvert=dup \
-sconvert=dup -f /
2. btrfs device delete / /dev/sdx
This greatly reduces the chances of the operation causing data loss due
to a read error during the device delete.
Signed-off-by: Austin S. Hemmelgarn ahferro...@gmail.com
---
fs/btrfs/volumes.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 07629e9..38a9522 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -3152,10 +3152,8 @@ int btrfs_balance(struct btrfs_balance_control
*bctl,
^^^, that should be a single line
num_devices--;
}
btrfs_dev_replace_unlock(fs_info-dev_replace);
- allowed = BTRFS_AVAIL_ALLOC_BIT_SINGLE;
- if (num_devices == 1)
- allowed |= BTRFS_BLOCK_GROUP_DUP;
- else if (num_devices 1)
+ allowed = BTRFS_AVAIL_ALLOC_BIT_SINGLE | BTRFS_BLOCK_GROUP_DUP;
+ if (num_devices 1)
allowed |= (BTRFS_BLOCK_GROUP_RAID0 |
BTRFS_BLOCK_GROUP_RAID1);
if (num_devices 2)
allowed |= BTRFS_BLOCK_GROUP_RAID5;
@@ -3221,6 +3219,21 @@ int btrfs_balance(struct btrfs_balance_control
*bctl,
^^^, ditto
goto out;
}
}
+ if (((bctl-sys.flags BTRFS_BALANCE_ARGS_CONVERT)
+ (bctl-sys.target ~BTRFS_BLOCK_GROUP_DUP) ||
+ (bctl-meta.flags BTRFS_BALANCE_ARGS_CONVERT)
+ (bctl-meta.target ~BTRFS_BLOCK_GROUP_DUP))
+ (num_devs 1)) {
+ if (bctl-flags BTRFS_BALANCE_FORCE) {
+ btrfs_info(fs_info, force conversion of
metadata
+ to dup profile on multiple
devices);
+ } else {
+ btrfs_err(fs_info, balance will reduce
metadata
+ integrity, use force if you want
this);
+
Re: [PATCH] btrfs: Allow forced conversion of metadata to dup profile on multiple devices
On 2014-02-24 09:12, Ilya Dryomov wrote:
On Mon, Feb 24, 2014 at 3:44 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 2014-02-24 08:37, Ilya Dryomov wrote:
On Thu, Feb 20, 2014 at 6:57 PM, David Sterba dste...@suse.cz wrote:
On Wed, Feb 19, 2014 at 11:10:41AM -0500, Austin S Hemmelgarn wrote:
Currently, btrfs balance start fails when trying to convert metadata or
system chunks to dup profile on filesystems with multiple devices. This
requires that a conversion from a multi-device filesystem to a single
device filesystem use the following methodology:
1. btrfs balance start -dconvert=single -mconvert=single \
-sconvert=single -f /
2. btrfs device delete / /dev/sdx
3. btrfs balance start -mconvert=dup -sconvert=dup /
This results in a period of time (possibly very long if the devices are
big) where you don't have the protection guarantees of multiple copies
of metadata chunks.
After applying this patch, one can instead use the following methodology
for conversion from a multi-device filesystem to a single device
filesystem:
1. btrfs balance start -dconvert=single -mconvert=dup \
-sconvert=dup -f /
2. btrfs device delete / /dev/sdx
This greatly reduces the chances of the operation causing data loss due
to a read error during the device delete.
Signed-off-by: Austin S. Hemmelgarn ahferro...@gmail.com
Reviewed-by: David Sterba dste...@suse.cz
Sounds useful. The muliple devices + DUP is allowed setup when the
device is added, this patch only adds the 'delete' counterpart. The
imroved data loss protection during the process is a good thing.
Hi,
Have you actually tried to queue it? Unless I'm missing something, it won't
compile, and on top of that, it seems to be corrupted too..
The patch itself was made using git, AFAICT it should be fine. I've
personally built and tested it using UML.
It doesn't look fine. It was generated with git, but it got corrupted
on the way: either how you pasted it or the email client you use is the
problem.
On Wed, Feb 19, 2014 at 6:10 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
Currently, btrfs balance start fails when trying to convert metadata or
system chunks to dup profile on filesystems with multiple devices. This
requires that a conversion from a multi-device filesystem to a single
device filesystem use the following methodology:
1. btrfs balance start -dconvert=single -mconvert=single \
-sconvert=single -f /
2. btrfs device delete / /dev/sdx
3. btrfs balance start -mconvert=dup -sconvert=dup /
This results in a period of time (possibly very long if the devices are
big) where you don't have the protection guarantees of multiple copies
of metadata chunks.
After applying this patch, one can instead use the following methodology
for conversion from a multi-device filesystem to a single device
filesystem:
1. btrfs balance start -dconvert=single -mconvert=dup \
-sconvert=dup -f /
2. btrfs device delete / /dev/sdx
This greatly reduces the chances of the operation causing data loss due
to a read error during the device delete.
Signed-off-by: Austin S. Hemmelgarn ahferro...@gmail.com
---
fs/btrfs/volumes.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 07629e9..38a9522 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -3152,10 +3152,8 @@ int btrfs_balance(struct btrfs_balance_control
*bctl,
^^^, that should be a single line
num_devices--;
}
btrfs_dev_replace_unlock(fs_info-dev_replace);
- allowed = BTRFS_AVAIL_ALLOC_BIT_SINGLE;
- if (num_devices == 1)
- allowed |= BTRFS_BLOCK_GROUP_DUP;
- else if (num_devices 1)
+ allowed = BTRFS_AVAIL_ALLOC_BIT_SINGLE | BTRFS_BLOCK_GROUP_DUP;
+ if (num_devices 1)
allowed |= (BTRFS_BLOCK_GROUP_RAID0 |
BTRFS_BLOCK_GROUP_RAID1);
if (num_devices 2)
allowed |= BTRFS_BLOCK_GROUP_RAID5;
@@ -3221,6 +3219,21 @@ int btrfs_balance(struct btrfs_balance_control
*bctl,
^^^, ditto
goto out;
}
}
+ if (((bctl-sys.flags BTRFS_BALANCE_ARGS_CONVERT)
+ (bctl-sys.target ~BTRFS_BLOCK_GROUP_DUP) ||
+ (bctl-meta.flags BTRFS_BALANCE_ARGS_CONVERT)
+ (bctl-meta.target ~BTRFS_BLOCK_GROUP_DUP))
+ (num_devs 1)) {
+ if (bctl-flags BTRFS_BALANCE_FORCE) {
+ btrfs_info(fs_info, force conversion of
metadata
+ to dup profile on multiple
devices);
+ } else {
+ btrfs_err(fs_info, balance will reduce
metadata
+
Re: kernel BUG at fs/btrfs/ctree.c:3215!
On Mon, Feb 24, 2014 at 1:45 PM, Tomasz Chmielewski t...@virtall.com wrote:
FYI, this crash was reproducible and was happening when using rsync
with --inplace option on a fragmented file:
# filefrag *
bayes_journal: 2 extents found
bayes_seen: 988 extents found
bayes_toks: 41 extents found
rsync process was hanging here:
var/lib/amavis/.spamassassin/
var/lib/amavis/.spamassassin/bayes_journal
(no more entries after that)
Mount option contains autodefrag; there were arond 20 snapshots of
that subvolume present.
After removing the fragmented file, it doesn't crash anymore. The size
of the file was around 80 MB.
Unfortunately I didn't check if the issue shows up with autodefrag
mount option disabled.
That seems to suggest a leaf is getting keys out of order.
I run often the patch below to catch such issues during development,
it requires having CONFIG_BTRFS_FS_CHECK_INTEGRITY=y in the kernel
config file. If CONFIG_BTRFS_ASSERT=y is set too, it causes a BUG_ON
whenever a key is written out of order to a leaf. It's useful for
debugging.
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index cc1b423..9fb4562 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3686,6 +3686,13 @@ void btrfs_mark_buffer_dirty(struct extent_buffer *buf)
__percpu_counter_add(root-fs_info-dirty_metadata_bytes,
buf-len,
root-fs_info-dirty_metadata_batch);
+#ifdef CONFIG_BTRFS_FS_CHECK_INTEGRITY
+ if (btrfs_header_level(buf) == 0 check_leaf(root, buf)) {
+ btrfs_print_leaf(root, buf);
+ ASSERT(0);
+ }
+#endif
}
static void __btrfs_btree_balance_dirty(struct btrfs_root *root,
--
Tomasz Chmielewski
http://wpkg.org
On Sun, 23 Feb 2014 12:25:28 +0100
Tomasz Chmielewski t...@virtall.com wrote:
Got this with 3.14-rc3:
[525983.966567] [ cut here ]
[525983.966645] kernel BUG at fs/btrfs/ctree.c:3215!
[525983.966705] invalid opcode: [#1] SMP
[525983.966765] Modules linked in: ipt_MASQUERADE iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
ip_tables x_tables cpufreq_ondemand cpufreq_conservative
cpufreq_powersave cpufreq_stats bridge stp llc ipv6 btrfs xor
raid6_pq zlib_deflate loop parport_pc parport battery button video
tpm_infineon tpm_tis tpm ehci_pci pcspkr acpi_cpufreq ehci_hcd
i2c_i801 i2c_core lpc_ich mfd_core ext4 crc16 jbd2 mbcache raid1 sg
sd_mod ahci libahci libata scsi_mod r8169 mii [525983.967240] CPU: 4
PID: 15321 Comm: btrfs-endio-wri Not tainted 3.14.0-rc3 #1
[525983.967351] Hardware name: System manufacturer System Product
Name/P8H77-M PRO, BIOS 1101 02/04/2013 [525983.967465] task:
8807f12a ti: 8805eb9f8000 task.ti: 8805eb9f8000
[525983.967576] RIP: 0010:[a02a8361] [a02a8361]
btrfs_set_item_key_safe+0xb2/0x119 [btrfs] [525983.967706] RSP:
0018:8805eb9f9b18 EFLAGS: 00010286 [525983.967766] RAX:
RBX: 000a RCX:
[525983.967877] RDX: 033c9000 RSI: 8805eb9f9c4f RDI:
8805eb9f9af7 [525983.967987] RBP: 8805eb9f9b68 R08:
8805eb9f9b38 R09: 88047c1ccc08 [525983.968098] R10:
1000 R11: 1600 R12: 88047c1ccb40
[525983.968209] R13: 8807e7c76360 R14: 8802a351a000 R15:
8805eb9f9c4f [525983.968321] FS: ()
GS:88081fb0() knlGS: [525983.968434] CS:
0010 DS: ES: CR0: 80050033 [525983.968494] CR2:
040f9fe8 CR3: 0160b000 CR4: 001407e0
[525983.968604] Stack: [525983.968657]
2600 6c00030f 033c5000 [525983.968773]
00030f26 8807e7c76360 88047c1ccb40 033e
[525983.96] 8805eb9f9ca8
a02d589d [525983.969003] Call Trace: [525983.969076]
[a02d589d] __btrfs_drop_extents+0x6c1/0xb12 [btrfs]
[525983.969155] [a02c9811]
insert_reserved_file_extent.constprop.63+0x9a/0x2a5 [btrfs]
[525983.969281] [a02ccebb]
btrfs_finish_ordered_io+0x265/0x3ef [btrfs] [525983.969403]
[a02cd055] finish_ordered_fn+0x10/0x12 [btrfs]
[525983.969481] [a02eb649] worker_loop+0x15e/0x495 [btrfs]
[525983.969556] [a02eb4eb] ?
btrfs_queue_worker+0x269/0x269 [btrfs] [525983.969623]
[81050c76] kthread+0xcd/0xd5 [525983.969685]
[81050ba9] ? kthread_freezable_should_stop+0x43/0x43
[525983.969749] [81398a7c] ret_from_fork+0x7c/0xb0
[525983.969811] [81050ba9] ?
kthread_freezable_should_stop+0x43/0x43 [525983.969873] Code: 8d 75
bf b9 11 00 00 00 4c 89 e7 48 63 d2 48 6b d2 19 48 83 c2 65 e8 b0 89
03 00 48 8d 7d bf 4c 89 fe e8 9e f5 ff ff 85 c0 7f 02 0f 0b 49 8b
47 09 48 63 d3 48 8d 75 bf 48 6b d2 19 b9 11 00 00 [525983.970116]
RIP [a02a8361]
[PATCH] btrfs-progs: mkfs.btrfs man page: update default metadata blocksize
Since commit c652e4ef changes default metadata blocksize, update corresponding options in man page. Signed-off-by: Rakesh Pandit rak...@tuxera.com --- man/mkfs.btrfs.8.in | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8.in index b54e935..dabeb62 100644 --- a/man/mkfs.btrfs.8.in +++ b/man/mkfs.btrfs.8.in @@ -47,10 +47,10 @@ there is a filesystem or partition table on the device already. .TP \fB\-n\fR, \fB\-\-nodesize \fIsize\fR \fB\-l\fR, \fB\-\-leafsize \fIsize\fR -Specify the nodesize, the tree block size in which btrfs stores data. The -default value is the page size. Must be a multiple of the sectorsize, but -not larger than 65536. Leafsize always equals nodesize and the options are -aliases. +Specify the nodesize, the tree block size in which btrfs stores +data. The default value is 16KB (16384) or the page size, whichever is +bigger. Must be a multiple of the sectorsize, but not larger than +65536. Leafsize always equals nodesize and the options are aliases. .TP \fB\-L\fR, \fB\-\-label \fIname\fR Specify a label for the filesystem. -- 1.8.3.1 -- 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: 3.13.5 kernel hangs some processes with btrfs
On Mon, Feb 24, 2014 at 07:29:58AM +, Duncan wrote: But I'm still seeing these, albeit less often. Any idea what they could be linked to? (I have a btrs send/receive going right now, it could hanging /mnt/btrfs_pool1 in a way that affects smbd, but the array feels ok otherwise, weird...) [ 1332.548370] INFO: task smbd:21882 blocked for more than 120 seconds. [ 1332.587455] Not tainted 3.13.5-ia32-i915-preempt-20140216 #1 [ 1332.625478] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. I've not seen anything like that here, but there are several kernel 3.13/3.14-rc reports of similar behavior on the list. I'll have to try this. Interestingly, I just got the following overnight. Something killed 3 different drives from software raid arrays, and the drives are all fine. It looks like btrfs hung my kernel hard enough that it messed up software raid, killed my array on which btrfs was, and then caused a cascade of further btrfs failures. Are those 2 traces useful? Many of these errors: [23721.563736] BUG: soft lockup - CPU#0 stuck for 22s! [btrfs:6140] [23721.601096] Modules linked in:[23721.601096] Modules linked in: ip6table_filter ip6table_filter ip6_tables ip6_tables ebtable_nat ebtable_nat ebtables ebtables tun tun ppdev ppdev lp lp autofs4 autofs4 binfmt_misc binfmt_misc kl5kusb105 kl5kusb105 deflate deflate ctr ctr twofish_generic twofish_generic twofish_common twofish_common camellia_generic camellia_generic serpent_generic serpent_generic blowfish_generic blowfish_generic blowfish_common blowfish_common cast5_generic cast5_generic cast_common cast_common ftdi_sio ftdi_sio des_generic des_generic keyspan keyspan cmac cmac xcbc xcbc rmd160 rmd160 sha512_generic sha512_generic crypto_null crypto_null af_key af_key xfrm_algo xfrm_algo dm_mirror dm_mirror dm_region_hash dm_region_hash dm_log dm_log nfsd nfsd nfs_acl nfs_acl auth_rpcgss auth_rpcgss nfs nfs fscache fscache lockd lockd sunrpc sunrpc ipt_REJECT ipt_REJECT xt_conntrack xt_conntrack xt_nat xt_nat xt_tcpudp xt_tcpudp xt_LOG xt_LOG iptable_mangle iptable_mangle iptable_filter iptable_filter fuse fuse lm85 lm85 hwmon_vid hwmon_vid dm_snapshot dm_snapshot iptable_nat iptable_nat ip_tables ip_tables nf_conntrack_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat_ipv4 nf_conntrack_ftp nf_conntrack_ftp ipt_MASQUERADE ipt_MASQUERADE nf_nat nf_nat x_tables x_tables nf_conntrack nf_conntrack sg sg st st snd_pcm_oss snd_pcm_oss snd_mixer_oss snd_mixer_oss snd_cmipci snd_cmipci gameport gameport microcode microcode snd_opl3_lib snd_opl3_lib snd_mpu401_uart snd_mpu401_uart kvm_intel kvm_intel snd_seq_midi snd_seq_midi kvm kvm eeepc_wmi eeepc_wmi snd_seq_midi_event snd_seq_midi_event rc_ati_x10 rc_ati_x10 asus_wmi asus_wmi ati_remote ati_remote snd_seq snd_seq sparse_keymap sparse_keymap coretemp coretemp asix asix snd_rawmidi snd_rawmidi snd_hda_codec_realtek snd_hda_codec_realtek parport_pc parport_pc libphy libphy intel_rapl intel_rapl rfkill rfkill parport parport pl2303 pl2303 x86_pkg_temp_thermal x86_pkg_temp_thermal snd_seq_device snd_seq_device intel_powerclamp intel_powerclamp rc_core rc_core usbnet usbnet wmi wmi ezusb ezusb tpm_tis tpm_tis tpm tpm pcspkr pcspkr usbserial usbserial snd_hda_intel snd_hda_intel evdev evdev snd_hda_codec snd_hda_codec i2c_i801 i2c_i801 snd_hwdep snd_hwdep snd_pcm snd_pcm snd_timer snd_timer processor processor lpc_ich lpc_ich xhci_hcd xhci_hcd snd snd soundcore soundcore snd_page_alloc snd_page_alloc xts xts gf128mul gf128mul dm_crypt dm_crypt dm_mod dm_mod raid456 raid456 async_raid6_recov async_raid6_recov async_pq async_pq async_xor async_xor async_memcpy async_memcpy async_tx async_tx e1000e e1000e ptp ptp pps_core pps_core ehci_pci ehci_pci r8169 r8169 ehci_hcd ehci_hcd sata_sil24 sata_sil24 sata_mv sata_mv thermal thermal mii mii crc32_pclmul crc32_pclmul crc32c_intel crc32c_intel fan fan usbcore usbcore usb_common usb_common [last unloaded: kl5kusb105] [last unloaded: kl5kusb105] [23722.377527] CPU: 0 PID: 6140 Comm: btrfs Not tainted 3.13.5-ia32-i915-preempt-20140216 #1 [23722.427962] Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3806 08/20/2012 [23722.484154] task: f1a00510 ti: c6f84000 task.ti: c6f84000 [23722.517991] EIP: 0060:[c119e324] EFLAGS: 0282 CPU: 0 [23722.552341] EIP is at btrfs_comp_cpu_keys+0x6/0x72 [23722.582497] EAX: c6f85cc7 EBX: ECX: 0d41 EDX: c6f85e05 [23722.621532] ESI: EDI: 0258 EBP: c6f85cbc ESP: c6f85cb0 [23722.660543] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [23722.694331] CR0: 80050033 CR2: b754df59 CR3: 2d7a5000 CR4: 000407d0 [23722.733354] Stack: [23722.746819] [23722.746819] 0258 0258 c6f85cdc c6f85cdc c119e3c1 c119e3c1 410002bd 410002bd 000d 000d 6c00 6c00 [23722.794851] 0010[23722.794851] 0010 02bd
Re: [PATCH 5/9] dcache: d_obtain_alias callers don't all want DISCONNECTED
On Thu, Feb 20, 2014 at 05:44:14PM -0800, Christoph Hellwig wrote: - return d_obtain_alias(inode); + return d_obtain_alias_root(inode); Can we call this d_obtain_root or similar, please? Yes, I like d_obtain_root better, done. I'll send out the updated series sometime. --b. -- 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 v5 3/3] btrfs-progs: Adds new par3456 modes to support up to six parities
Extends mkfs.btrfs to support the new par1/2/3/4/5/6 modes to create
filesystem with up to six parities.
Replaces the raid6 code with a new references function able to compute up
to six parities.
Replaces the existing BLOCK_GROUP_RAID5/6 with new PAR1/2/3/4/5/6 ones that
handle up to six parities, and updates all the code to use them.
Signed-off-by: Andrea Mazzoleni amadva...@gmail.com
---
Makefile| 14 ++-
chunk-recover.c | 18 +---
cmds-balance.c | 20 +++-
cmds-check.c| 7 +-
cmds-chunk.c| 18 +---
cmds-filesystem.c | 12 ++-
ctree.h | 42 -
disk-io.h | 2 -
extent-tree.c | 3 +-
ioctl.h | 18 +++-
man/mkfs.btrfs.8.in | 4 +-
mkfs.c | 28 +-
mktables.c | 256
raid.c | 44 +
raid.h | 34 +++
raid6.c | 101 -
utils.c | 12 ++-
volumes.c | 112 ++-
volumes.h | 12 ++-
19 files changed, 530 insertions(+), 227 deletions(-)
create mode 100644 mktables.c
create mode 100644 raid.c
create mode 100644 raid.h
delete mode 100644 raid6.c
diff --git a/Makefile b/Makefile
index 0874a41..72c5c01 100644
--- a/Makefile
+++ b/Makefile
@@ -9,7 +9,7 @@ CFLAGS = -g -O1 -fno-strict-aliasing
objects = ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o \
root-tree.o dir-item.o file-item.o inode-item.o inode-map.o \
extent-cache.o extent_io.o volumes.o utils.o repair.o \
- qgroup.o raid6.o free-space-cache.o list_sort.o
+ qgroup.o raid.o tables.o free-space-cache.o list_sort.o
cmds_objects = cmds-subvolume.o cmds-filesystem.o cmds-device.o cmds-scrub.o \
cmds-inspect.o cmds-balance.o cmds-send.o cmds-receive.o \
cmds-quota.o cmds-qgroup.o cmds-replace.o cmds-check.o \
@@ -140,6 +140,10 @@ version.h:
@echo [SH] $@
$(Q)bash version.sh
+tables.c: mktables
+ @echo [MK] $@
+ $(Q)./mktables tables.c
+
$(libs_shared): $(libbtrfs_objects) $(lib_links) send.h
@echo [LD] $@
$(Q)$(CC) $(CFLAGS) $(libbtrfs_objects) $(LDFLAGS) $(lib_LIBS) \
@@ -193,6 +197,10 @@ mkfs.btrfs: $(objects) $(libs) mkfs.o
@echo [LD] $@
$(Q)$(CC) $(CFLAGS) -o mkfs.btrfs $(objects) mkfs.o $(LDFLAGS) $(LIBS)
+mktables: $(libs) mktables.o
+ @echo [LD] $@
+ $(Q)$(CC) $(CFLAGS) -o mktables mktables.o $(LDFLAGS) $(LIBS)
+
mkfs.btrfs.static: $(static_objects) mkfs.static.o $(static_libbtrfs_objects)
@echo [LD] $@
$(Q)$(CC) $(STATIC_CFLAGS) -o mkfs.btrfs.static mkfs.static.o
$(static_objects) \
@@ -225,8 +233,8 @@ clean: $(CLEANDIRS)
@echo Cleaning
$(Q)rm -f $(progs) cscope.out *.o *.o.d btrfs-convert btrfs-image
btrfs-select-super \
btrfs-zero-log btrfstune dir-test ioctl-test quick-test send-test
btrfsck \
- btrfs.static mkfs.btrfs.static btrfs-calc-size \
- version.h $(check_defs) \
+ btrfs.static mkfs.btrfs.static btrfs-calc-size mktables \
+ version.h tables.c $(check_defs) \
$(libs) $(lib_links)
$(CLEANDIRS):
diff --git a/chunk-recover.c b/chunk-recover.c
index bcde39e..cec14cd 100644
--- a/chunk-recover.c
+++ b/chunk-recover.c
@@ -1327,8 +1327,7 @@ static int calc_num_stripes(u64 type)
{
if (type (BTRFS_BLOCK_GROUP_RAID0 |
BTRFS_BLOCK_GROUP_RAID10 |
- BTRFS_BLOCK_GROUP_RAID5 |
- BTRFS_BLOCK_GROUP_RAID6))
+ BTRFS_BLOCK_GROUP_PARX))
return 0;
else if (type (BTRFS_BLOCK_GROUP_RAID1 |
BTRFS_BLOCK_GROUP_DUP))
@@ -1404,13 +1403,8 @@ static int btrfs_calc_stripe_index(struct chunk_record
*chunk, u64 logical)
} else if (chunk-type_flags BTRFS_BLOCK_GROUP_RAID10) {
index = stripe_nr % (chunk-num_stripes / chunk-sub_stripes);
index *= chunk-sub_stripes;
- } else if (chunk-type_flags BTRFS_BLOCK_GROUP_RAID5) {
- nr_data_stripes = chunk-num_stripes - 1;
- index = stripe_nr % nr_data_stripes;
- stripe_nr /= nr_data_stripes;
- index = (index + stripe_nr) % chunk-num_stripes;
- } else if (chunk-type_flags BTRFS_BLOCK_GROUP_RAID6) {
- nr_data_stripes = chunk-num_stripes - 2;
+ } else if (chunk-type_flags BTRFS_BLOCK_GROUP_PARX) {
+ nr_data_stripes = chunk-num_stripes -
btrfs_flags_par(chunk-type_flags);
index = stripe_nr % nr_data_stripes;
stripe_nr /= nr_data_stripes;
index = (index + stripe_nr) % chunk-num_stripes;
@@ -1503,8 +1497,7 @@ no_extent_record:
if (list_empty(devexts))
return 0;
- if
[PATCH v5 0/3] New RAID library supporting up to six parities
Hi, A new version of the new RAID library. Finally with *working* btrfs support! It includes patches for both the kernel and btrfs-progs to add new parity modes par3, par4, par5 and par6 working similarly at the existing raid5 and raid6 ones. The patches apply cleanly to kernel v3.14-rc3 and btrfs-progs v3.12. If you are willing to test it, you can do something like that: mkfs.btrfs -d par3 -m par3 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 mount /dev/sdb1 /mnt/tmp ...copy something to /mnt/tmp... md5deep -r /mnt/tmp test_before.hash umount /mnt/tmp dd if=/dev/urandom of=/dev/sdc1 count=... dd if=/dev/urandom of=/dev/sdd1 count=... dd if=/dev/urandom of=/dev/sde1 count=... mount -o degraded /dev/sdb1 /mnt/tmp md5deep -r /mnt/tmp test_after.hash umount /mnt/tmp diff -u test_before.hash test_after.hash echo OK I run various test like that, and everything seems to work. The first patch is the new RAID library for the kernel, supporting up to six parities. It's verified with automated test that reach 99.3% code coverage. It also passes clang and valgrind tests with no error. It applies cleanly to kernel v3.14-rc3, but it should work with any other version because it's formed only of new files. The only kernel change is the new CONFIG_RAID_CAUCHY option in the lib configuration section. For reviewing I recommend to start from the include/raid/raid.h that describes the new generic raid interface. Then continue in lib/raid/raid.c where the interface is implement. You can start reading the documentation about the RAID mathematics used, taking care that its correctness is proven both mathematically and by brute-force by the test programs. You can then review raid_gen() and raid_rec(), that are high level forwarders to generic and optimized asm functions that generate parity and recover data. Their internal structure is very similar at the functions in RAID6. The main difference is to have a generic matrix of parity coefficients. All these functions are verified by the test programs, with full lines and branches coverage, meaning that you can concentrate the review on their structure, than in the computation and asm details. Finally, you can review the test programs in lib/raid/test, to ensure that everything is really tested, and the coverage test can help you on that. The second patch contains the kernel btrfs modifications. Besides adding the new parity modes it also removes a lot of code about raid details that are now handled by the new raid library. It applies cleanly to kernel v3.14-rc3. You can use it also for previous kernels, with an obvious adjustment in fs/btrfs/ctree.h. For reviewing you can start from the diff, and check chunk after chunk. Likely the two most complex changes are where the new raid_gen() and raid_rec() are called replacing big chunks of code. But the rest is mostly straightforward as I just extended all the checks about RAID5 and RAID6 to six parities. But for sure it needs a more careful review as my knowledge of btrfs internals is very limited. The third patch contains the btrfs-progs modification. They are just matching the kernel changes, and the same considerations apply. It applies cleanly to btrfs-progs v3.12. Please let me know what you think, and if it can be considered for inclusion or something more is required. If some patch is missing due mailinglist size limit, you can download them at: http://snapraid.sourceforge.net/linux/v5/ You can see the code coverage analysis made by lcov at: http://snapraid.sourceforge.net/linux/v5/coverage/ Changes from v4 to v5: - Adds more comments in the libraid patch. - Reviews and completes the btrfs patch. The previous patch was not really working due some missing pieces. - Adds a new patch for btrfs-progs to extend the mkfs.btrfs functionality to create filesystem with up to six parity levels. - Removes the async_tx patch as not yet ready for inclusion. Changes from v3 to v4: - Adds a code coverage test - Adds a matrix inversion test. - Everything updated to kernel 3.13. Changes from v2 to v3: - Adds a new patch to change async_tx to use the new raid library for synchronous cases and to export a similar interface. Also modified md/raid5.c to use the new interface of async_tx. This is just example code not meant for inclusion! - Renamed raid_par() to raid_gen() to match better existing naming. - Removed raid_sort() and replaced with raid_insert() that allows to build a vector already in order instead of sorting it later. This function is declared in the new raid/helper.h. - Better documentation in the raid.h/c files. Start from raid.h to see the documentation of the new interface. Changes from v1 to v2: - Adds a patch to btrfs to extend its support to more than double parity. This is just example code not meant for inclusion! - Changes the main raid_rec() interface to merge the failed data and parity index vectors. This matches better the kernel usage. - Uses
[PATCH v5 2/3] fs: btrfs: Adds new par3456 modes to support up to six parities
Removes the RAID logic now handled in the new raid_gen() and raid_rec() calls
that hide all the details.
Replaces the faila/failb failure indexes with a fail[] vector that keeps
track of up to six failures.
Replaces the existing BLOCK_GROUP_RAID5/6 with new PAR1/2/3/4/5/6 ones that
handle up to six parities, and updates all the code to use them.
Signed-off-by: Andrea Mazzoleni amadva...@gmail.com
---
fs/btrfs/Kconfig | 1 +
fs/btrfs/ctree.h | 50 ++--
fs/btrfs/disk-io.c | 7 +-
fs/btrfs/extent-tree.c | 67 +++
fs/btrfs/inode.c | 3 +-
fs/btrfs/raid56.c| 273 ++-
fs/btrfs/raid56.h| 19 ++-
fs/btrfs/scrub.c | 3 +-
fs/btrfs/volumes.c | 144 +++
include/trace/events/btrfs.h | 16 ++-
include/uapi/linux/btrfs.h | 19 ++-
11 files changed, 313 insertions(+), 289 deletions(-)
diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
index a66768e..fb011b8 100644
--- a/fs/btrfs/Kconfig
+++ b/fs/btrfs/Kconfig
@@ -6,6 +6,7 @@ config BTRFS_FS
select ZLIB_DEFLATE
select LZO_COMPRESS
select LZO_DECOMPRESS
+ select RAID_CAUCHY
select RAID6_PQ
select XOR_BLOCKS
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 2c1a42c..7e6d2bf 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -522,6 +522,7 @@ struct btrfs_super_block {
#define BTRFS_FEATURE_INCOMPAT_RAID56 (1ULL 7)
#define BTRFS_FEATURE_INCOMPAT_SKINNY_METADATA (1ULL 8)
#define BTRFS_FEATURE_INCOMPAT_NO_HOLES(1ULL 9)
+#define BTRFS_FEATURE_INCOMPAT_PAR3456 (1ULL 10)
#define BTRFS_FEATURE_COMPAT_SUPP 0ULL
#define BTRFS_FEATURE_COMPAT_SAFE_SET 0ULL
@@ -539,7 +540,8 @@ struct btrfs_super_block {
BTRFS_FEATURE_INCOMPAT_RAID56 |\
BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF | \
BTRFS_FEATURE_INCOMPAT_SKINNY_METADATA | \
-BTRFS_FEATURE_INCOMPAT_NO_HOLES)
+BTRFS_FEATURE_INCOMPAT_NO_HOLES | \
+BTRFS_FEATURE_INCOMPAT_PAR3456)
#define BTRFS_FEATURE_INCOMPAT_SAFE_SET\
(BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF)
@@ -983,8 +985,39 @@ struct btrfs_dev_replace_item {
#define BTRFS_BLOCK_GROUP_RAID1(1ULL 4)
#define BTRFS_BLOCK_GROUP_DUP (1ULL 5)
#define BTRFS_BLOCK_GROUP_RAID10 (1ULL 6)
-#define BTRFS_BLOCK_GROUP_RAID5 (1ULL 7)
-#define BTRFS_BLOCK_GROUP_RAID6 (1ULL 8)
+#define BTRFS_BLOCK_GROUP_PAR1 (1ULL 7)
+#define BTRFS_BLOCK_GROUP_PAR2 (1ULL 8)
+#define BTRFS_BLOCK_GROUP_PAR3 (1ULL 9)
+#define BTRFS_BLOCK_GROUP_PAR4 (1ULL 10)
+#define BTRFS_BLOCK_GROUP_PAR5 (1ULL 11)
+#define BTRFS_BLOCK_GROUP_PAR6 (1ULL 12)
+
+/* tags for all the parity groups */
+#define BTRFS_BLOCK_GROUP_PARX (BTRFS_BLOCK_GROUP_PAR1 | \
+ BTRFS_BLOCK_GROUP_PAR2 | \
+ BTRFS_BLOCK_GROUP_PAR3 | \
+ BTRFS_BLOCK_GROUP_PAR4 | \
+ BTRFS_BLOCK_GROUP_PAR5 | \
+ BTRFS_BLOCK_GROUP_PAR6)
+
+/* gets the parity number from the parity group */
+static inline int btrfs_flags_par(unsigned group)
+{
+ switch (group BTRFS_BLOCK_GROUP_PARX) {
+ case BTRFS_BLOCK_GROUP_PAR1: return 1;
+ case BTRFS_BLOCK_GROUP_PAR2: return 2;
+ case BTRFS_BLOCK_GROUP_PAR3: return 3;
+ case BTRFS_BLOCK_GROUP_PAR4: return 4;
+ case BTRFS_BLOCK_GROUP_PAR5: return 5;
+ case BTRFS_BLOCK_GROUP_PAR6: return 6;
+ }
+
+ /* ensures that no multiple groups are defined */
+ BUG_ON(group BTRFS_BLOCK_GROUP_PARX);
+
+ return 0;
+}
+
#define BTRFS_BLOCK_GROUP_RESERVED BTRFS_AVAIL_ALLOC_BIT_SINGLE
enum btrfs_raid_types {
@@ -993,8 +1026,12 @@ enum btrfs_raid_types {
BTRFS_RAID_DUP,
BTRFS_RAID_RAID0,
BTRFS_RAID_SINGLE,
- BTRFS_RAID_RAID5,
- BTRFS_RAID_RAID6,
+ BTRFS_RAID_PAR1,
+ BTRFS_RAID_PAR2,
+ BTRFS_RAID_PAR3,
+ BTRFS_RAID_PAR4,
+ BTRFS_RAID_PAR5,
+ BTRFS_RAID_PAR6,
BTRFS_NR_RAID_TYPES
};
@@ -1004,8 +1041,7 @@ enum btrfs_raid_types {
#define BTRFS_BLOCK_GROUP_PROFILE_MASK (BTRFS_BLOCK_GROUP_RAID0 | \
BTRFS_BLOCK_GROUP_RAID1 | \
-BTRFS_BLOCK_GROUP_RAID5 | \
-BTRFS_BLOCK_GROUP_RAID6 | \
+BTRFS_BLOCK_GROUP_PARX |\
BTRFS_BLOCK_GROUP_DUP | \
BTRFS_BLOCK_GROUP_RAID10)
/*
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 81ea553..9931cf3 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3337,12
Re: [PATCH] xfstests: add function _require_fssum()
On Mon, Feb 24, 2014 at 01:22:36PM +, Filipe David Manana wrote:
On Mon, Feb 24, 2014 at 12:23 PM, Dave Chinner da...@fromorbit.com wrote:
On Mon, Feb 24, 2014 at 11:56:23AM +, Filipe David Borba Manana wrote:
To avoid repeating detection of fssum presence in many btrfs tests, as
suggested by Dave Chinner.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
common/rc |7 +++
tests/btrfs/007 |5 +
tests/btrfs/016 |5 +
tests/btrfs/030 |5 +
tests/btrfs/038 |5 +
tests/btrfs/039 |5 +
tests/btrfs/040 |5 +
tests/btrfs/041 |5 +
tests/btrfs/042 |5 +
9 files changed, 15 insertions(+), 32 deletions(-)
mode change 100644 = 100755 tests/btrfs/016
diff --git a/common/rc b/common/rc
index 5df504c..cce05cc 100644
--- a/common/rc
+++ b/common/rc
@@ -2144,6 +2144,13 @@ _require_cp_reflink()
_notrun This test requires a cp with --reflink support.
}
+_require_fssum()
+{
+ HERE=`pwd`
+ FSSUM_PROG=$HERE/src/fssum
+ [ -x $FSSUM_PROG ] || _notrun fssum not built
+}
$here is defined by check to be the root of the xfstests instance
that is running. There's 60+ tests that already us it. Hence:
_require_fssum()
{
FSSUM_PROG=$here/src/fssum
[ -x $FSSUM_PROG ] || _notrun fssum not built
}
Is all you need here.
Hum, doesn't work unless the test file defines $here. At least when
running a single only (.e.g. ./check btrfs/041).
Right, I realised that it isn't exported from check, and the template
for new tests defines it as:
here=\`pwd\`
which is essentially the same thing. Almost every test does it.
$ git grep here=\`pwd\` |wc -l
364
And it works just fine when running a test as you describe above.
Many of the _requires* functions just use $here directly, and does a
lot of the common/* infrastructure. It is assumed that $here is set
and valid and so if it wasn't set, lots of different things would
break.
Oh, I note that btrfs/034 and btrfs/037 don't set it, so they need
fixing, too.
Looking at it, though, we shoul djust export the value from check
and remove the assignment that occurs in every test as they end up
being the same value:
$ sudo ./check generic/001
check_here=/home/dave/src/xfstests-dev
FSTYP -- xfs (debug)
PLATFORM -- Linux/x86_64 test2 3.14.0-rc3-dgc+
MKFS_OPTIONS -- -f -bsize=4096 /dev/vdb
MOUNT_OPTIONS -- /dev/vdb /mnt/scratch
generic/001 5s ... [failed, exit status 1] - output mismatch (see
/home/dave/src/xfstests-dev/results//generic/001.out.bad)
.
$ cat /home/dave/src/xfstests-dev/results//generic/001.out.bad
QA output created by 001
here=/home/dave/src/xfstests-dev
$
diff --git a/tests/btrfs/007 b/tests/btrfs/007
index 5df9ccb..5430613 100755
--- a/tests/btrfs/007
+++ b/tests/btrfs/007
@@ -31,7 +31,6 @@ seq=`basename $0`
seqres=$RESULT_DIR/$seq
echo QA output created by $seq
-here=`pwd`
tmp=`mktemp -d`
status=1
Yeah, redefining $here is a bad thing to do :/
Right, my mistake. It needs to be defined for the entire test, not
in a requires function. Hence I think we should just export it from
check
It also points out that the btrfs tests are using a non-standard
$tmp directory - one that is in the xfstests source directory.
That's a bad thing, too - tests should be using:
tmp=/tmp/$$
to store small temporary files.
If /tmp is too small for what a test needs, then the test should be
using $TEST_DIR as the store for the temporary files to exercise
the filesystem under test as much as possible. e.g. send image
files build form snapshots of SCRATCH_DEV should be stored on TEST_DIR,
not in $tmp; filesystem image files that are mounted by loopback
should be stored on TEST_DIR or SCRATCH_MNT, not $tmp. And so on.
i.e. the idea is that you direct as much of the IO to the test_DIR
and SCRATCH_MNT as possible, not to the filesystem that is hosting
$tmp or the xfstests source directory
Right. Sounds like a separate patch (to use TEST_DIR/$$ for e.g. as a
place to store temporary test data).
tmp should be set to /tmp/$$. That's where the *test harness* will
direct temporary log files, mkfs output, etc. If you have temporary
data for the *test*, and it's large, use TEST_DIR, not $tmp.
$tmp is generally only for things like log files, time stamps,
output files that need later processing because they can't be
filtered directly, etc.
Why? Because if the test corrupts $TEST_DIR and you've got all the
test harness tmp files on TEST_DIR, how is the test harness going
to work out what went wrong during the test?
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: [PATCH] Btrfs-progs: fsck: fix wrong return value in check_block()
On Mon, Feb 24, 2014 at 5:55 AM, Wang Shilong wangsl.f...@cn.fujitsu.com wrote: We found btrfsck will output backrefs mismatch while the filesystem is defenitely ok. The problem is that check_block() don't return right value,which makes btrfsck won't walk all tree blocks thus we don't get a consistent filesystem, we will fail to check extent refs etc. Reported-by: Gui Hecheng guihc.f...@cn.fujitsu.com Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com --- cmds-check.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmds-check.c b/cmds-check.c index a2afae6..253569f 100644 --- a/cmds-check.c +++ b/cmds-check.c @@ -2477,7 +2477,7 @@ static int check_block(struct btrfs_trans_handle *trans, struct cache_extent *cache; struct btrfs_key key; enum btrfs_tree_block_status status; - int ret = 1; + int ret = 0; int level; cache = lookup_cache_extent(extent_cache, buf-start, buf-len); -- I tried this fix on a broken btrfs volume I've been trying to repair, and it seemed to put me in an infinite loop. I agree that something seems wrong with the way the caller of check_block uses the return value, and I also noticed that it seemed to exit before walking all the tree blocks. But I think the problem is more subtle than flipping the default ret value from 1 to 0. -- 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] xfstests: add function _require_fssum()
On Mon, Feb 24, 2014 at 10:22 PM, Dave Chinner da...@fromorbit.com wrote:
On Mon, Feb 24, 2014 at 01:22:36PM +, Filipe David Manana wrote:
On Mon, Feb 24, 2014 at 12:23 PM, Dave Chinner da...@fromorbit.com wrote:
On Mon, Feb 24, 2014 at 11:56:23AM +, Filipe David Borba Manana wrote:
To avoid repeating detection of fssum presence in many btrfs tests, as
suggested by Dave Chinner.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
common/rc |7 +++
tests/btrfs/007 |5 +
tests/btrfs/016 |5 +
tests/btrfs/030 |5 +
tests/btrfs/038 |5 +
tests/btrfs/039 |5 +
tests/btrfs/040 |5 +
tests/btrfs/041 |5 +
tests/btrfs/042 |5 +
9 files changed, 15 insertions(+), 32 deletions(-)
mode change 100644 = 100755 tests/btrfs/016
diff --git a/common/rc b/common/rc
index 5df504c..cce05cc 100644
--- a/common/rc
+++ b/common/rc
@@ -2144,6 +2144,13 @@ _require_cp_reflink()
_notrun This test requires a cp with --reflink support.
}
+_require_fssum()
+{
+ HERE=`pwd`
+ FSSUM_PROG=$HERE/src/fssum
+ [ -x $FSSUM_PROG ] || _notrun fssum not built
+}
$here is defined by check to be the root of the xfstests instance
that is running. There's 60+ tests that already us it. Hence:
_require_fssum()
{
FSSUM_PROG=$here/src/fssum
[ -x $FSSUM_PROG ] || _notrun fssum not built
}
Is all you need here.
Hum, doesn't work unless the test file defines $here. At least when
running a single only (.e.g. ./check btrfs/041).
Right, I realised that it isn't exported from check, and the template
for new tests defines it as:
here=\`pwd\`
which is essentially the same thing. Almost every test does it.
$ git grep here=\`pwd\` |wc -l
364
And it works just fine when running a test as you describe above.
Many of the _requires* functions just use $here directly, and does a
lot of the common/* infrastructure. It is assumed that $here is set
and valid and so if it wasn't set, lots of different things would
break.
Oh, I note that btrfs/034 and btrfs/037 don't set it, so they need
fixing, too.
Looking at it, though, we shoul djust export the value from check
and remove the assignment that occurs in every test as they end up
being the same value:
$ sudo ./check generic/001
check_here=/home/dave/src/xfstests-dev
FSTYP -- xfs (debug)
PLATFORM -- Linux/x86_64 test2 3.14.0-rc3-dgc+
MKFS_OPTIONS -- -f -bsize=4096 /dev/vdb
MOUNT_OPTIONS -- /dev/vdb /mnt/scratch
generic/001 5s ... [failed, exit status 1] - output mismatch (see
/home/dave/src/xfstests-dev/results//generic/001.out.bad)
.
$ cat /home/dave/src/xfstests-dev/results//generic/001.out.bad
QA output created by 001
here=/home/dave/src/xfstests-dev
$
diff --git a/tests/btrfs/007 b/tests/btrfs/007
index 5df9ccb..5430613 100755
--- a/tests/btrfs/007
+++ b/tests/btrfs/007
@@ -31,7 +31,6 @@ seq=`basename $0`
seqres=$RESULT_DIR/$seq
echo QA output created by $seq
-here=`pwd`
tmp=`mktemp -d`
status=1
Yeah, redefining $here is a bad thing to do :/
Right, my mistake. It needs to be defined for the entire test, not
in a requires function. Hence I think we should just export it from
check
Hum, ok. So the decision is to let the tests explicitly define the
variable here, and not export here from the main check script.
It also points out that the btrfs tests are using a non-standard
$tmp directory - one that is in the xfstests source directory.
That's a bad thing, too - tests should be using:
tmp=/tmp/$$
to store small temporary files.
If /tmp is too small for what a test needs, then the test should be
using $TEST_DIR as the store for the temporary files to exercise
the filesystem under test as much as possible. e.g. send image
files build form snapshots of SCRATCH_DEV should be stored on TEST_DIR,
not in $tmp; filesystem image files that are mounted by loopback
should be stored on TEST_DIR or SCRATCH_MNT, not $tmp. And so on.
i.e. the idea is that you direct as much of the IO to the test_DIR
and SCRATCH_MNT as possible, not to the filesystem that is hosting
$tmp or the xfstests source directory
Right. Sounds like a separate patch (to use TEST_DIR/$$ for e.g. as a
place to store temporary test data).
tmp should be set to /tmp/$$. That's where the *test harness* will
direct temporary log files, mkfs output, etc. If you have temporary
data for the *test*, and it's large, use TEST_DIR, not $tmp.
$tmp is generally only for things like log files, time stamps,
output files that need later processing because they can't be
filtered directly, etc.
Why? Because if the test corrupts $TEST_DIR and you've got all the
test harness tmp files on TEST_DIR, how is the test harness going
to work out what went wrong during the test?
Makes sense. All these btrfs tests
Re: [PATCH] xfstests: add function _require_fssum()
On Mon, Feb 24, 2014 at 11:08:27PM +, Filipe David Manana wrote: On Mon, Feb 24, 2014 at 10:22 PM, Dave Chinner da...@fromorbit.com wrote: On Mon, Feb 24, 2014 at 01:22:36PM +, Filipe David Manana wrote: On Mon, Feb 24, 2014 at 12:23 PM, Dave Chinner da...@fromorbit.com wrote: diff --git a/tests/btrfs/007 b/tests/btrfs/007 index 5df9ccb..5430613 100755 --- a/tests/btrfs/007 +++ b/tests/btrfs/007 @@ -31,7 +31,6 @@ seq=`basename $0` seqres=$RESULT_DIR/$seq echo QA output created by $seq -here=`pwd` tmp=`mktemp -d` status=1 Yeah, redefining $here is a bad thing to do :/ Right, my mistake. It needs to be defined for the entire test, not in a requires function. Hence I think we should just export it from check Hum, ok. So the decision is to let the tests explicitly define the variable here, and not export here from the main check script. Well, that's the status quo right now. What I'm suggesting is that we should just export it from check and get rid of it from each test as a separate cleanup. i.e. It always needs to be set to the same value (i.e. the root of the xfstests tree) so there is no reason why it should not be set up once in a central location. 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: [PATCH] Btrfs-progs: fsck: fix wrong return value in check_block()
Hi Mitch, On 02/25/2014 07:03 AM, Mitch Harder wrote: On Mon, Feb 24, 2014 at 5:55 AM, Wang Shilong wangsl.f...@cn.fujitsu.com wrote: We found btrfsck will output backrefs mismatch while the filesystem is defenitely ok. The problem is that check_block() don't return right value,which makes btrfsck won't walk all tree blocks thus we don't get a consistent filesystem, we will fail to check extent refs etc. Reported-by: Gui Hecheng guihc.f...@cn.fujitsu.com Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com --- cmds-check.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmds-check.c b/cmds-check.c index a2afae6..253569f 100644 --- a/cmds-check.c +++ b/cmds-check.c @@ -2477,7 +2477,7 @@ static int check_block(struct btrfs_trans_handle *trans, struct cache_extent *cache; struct btrfs_key key; enum btrfs_tree_block_status status; - int ret = 1; + int ret = 0; int level; cache = lookup_cache_extent(extent_cache, buf-start, buf-len); -- I tried this fix on a broken btrfs volume I've been trying to repair, and it seemed to put me in an infinite loop. I agree that something seems wrong with the way the caller of check_block uses the return value, and I also noticed that it seemed to exit before walking all the tree blocks. But I think the problem is more subtle than flipping the default ret value from 1 to 0. No, not really even though i know there are other problems with fsck repair mode. But this problem should be fixed and pushed into btrfs-progsv3.13.(Notice, the below problem did not exist in btrfs-progsv3.12) An easy way to trigger this problem: # mkfs.btrfs -f /dev/sda9 # mount /dev/sda9 /mnt # dd if=/dev/zero of=/mnt/data bs=4k count=10240 oflag=direct # btrfs sub snapshot /mnt /mnt/snap1 # btrfs sub snapshot /mnt /mnt/snap2 # umount /mnt # btrfs check /dev/sda9 After applying this patch, the above problems did not exist. Feel free to correct me if i miss something here.^_^ Thanks, Wang -- 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 for xfstests] xfstests: fix to make tests/btrfs/013 really work
Hi Wang, Thank you for reviewing my patch. I ran the test using btrfs progs v0.19(OpenSuse 12.3) previously and got a fail situation. I verified v3.12 this morning and it work well as you mentioned. Althouth the new version doesn't have this problem, I think it would be better to fix this. I'll fix the titile and resend it. On 2014/2/24 19:02, Wang Shilong wrote: Hi Zhang, On 02/24/2014 06:51 PM, ZhangZhen wrote: The test 013 couldn't work because here lacked start. This patch fix it. Signed-off-by: Zhang Zhenzhenzhang.zh...@huawei.com --- tests/btrfs/013 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/btrfs/013 b/tests/btrfs/013 index 7620fcc..fb81663 100644 --- a/tests/btrfs/013 +++ b/tests/btrfs/013 @@ -72,7 +72,7 @@ _check_csum_error() } $XFS_IO_PROG -f -c falloc 0 1M -c pwrite 16k 8k -c fsync \ $SCRATCH_MNT/foo $seqres.full 21 -$BTRFS_UTIL_PROG filesystem balance $SCRATCH_MNT $seqres.full 21 || \ +$BTRFS_UTIL_PROG filesystem balance start $SCRATCH_MNT $seqres.full 21 || \ _fail balance failed Due to historical reasons, we have 'btrfs file balance '.. Until now, it is also ok to run 'btrfs file balance mnt', and it has equal effect as 'btrfs filesystem balance start'. Anyway, using latest 'btrfs file balance start mnt' is better than previous codes..but patch's title is not right any more... BTW,Dave Chinner previously pointed out that we need a cleanup, url can be seen: http://oss.sgi.com/archives/xfs/2014-02/msg00482.html Thanks, Wang _scratch_unmount _scratch_mount -- 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: fix to make tests/btrfs/013 work using all version btrfs progs
The test 013 couldn't work using some old version btrfs progs e.g.(btrfs progs v0.19 openSUSE 12.3)because here lacked start. This patch fix it. Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com --- tests/btrfs/013 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/btrfs/013 b/tests/btrfs/013 index 7620fcc..fb81663 100644 --- a/tests/btrfs/013 +++ b/tests/btrfs/013 @@ -72,7 +72,7 @@ _check_csum_error() } $XFS_IO_PROG -f -c falloc 0 1M -c pwrite 16k 8k -c fsync \ $SCRATCH_MNT/foo $seqres.full 21 -$BTRFS_UTIL_PROG filesystem balance $SCRATCH_MNT $seqres.full 21 || \ +$BTRFS_UTIL_PROG filesystem balance start $SCRATCH_MNT $seqres.full 21 || \ _fail balance failed _scratch_unmount _scratch_mount -- 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: How to identify if a partition containing a btrfs volume is mounted and where
Thanks Hugo for the heads-up. I am trying to enhance GParted (http://www.gparted.org/) to better support btrfs, specifically multi-device ones. GParted displays the busy status (mounted or not) and the mount point of each partition. For a single device file system this is easy. Entry in /proc/mounts for the partition identifies it's mounted and provides the mount point. In the general case for btrfs I don't know how to get from device name containing a btrfs volume to knowing if it's mounted and where? :: btrfs filesystem show can identify the devices in a btrfs, if its not for the final sync-up, I had posted a patch which shows mount-point in the btrfs fi show -m output that should help you as of now, I have plans of revising it later and make it integration ready. # mkfs.btrfs /dev/sdb2 /dev/sdb3 /dev/sdb4 # mount /dev/sdb2 /mnt/1 # btrfs device delete /dev/sdb2 /mnt/1 So /dev/sdb2 is no longer part of the file system, but it's still mounted using it. # grep btrfs /proc/mounts /dev/sdb2 /mnt/1 btrfs rw,seclabel,relatime,ssd,space_cache 0 0 This bug isn't there is the current btrfs-next. I couldn't reproduce. Anand posted some kernel patches for an ioctl a few weeks ago that would allow you to get hold of the kernel's UUID-device mapping. yes btrfs-devlist is WIP. As of now I am looking for some help as in here: http://www.spinics.net/lists/linux-fsdevel/msg72861.html OR http://www.spinics.net/lists/linux-btrfs/msg31784.html Team, Any help ? Thanks. Anand -- 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: 3.14rc3 kernel also hangs some processes with btrfs
On Mon, Feb 24, 2014 at 09:35:19AM -0800, Marc MERLIN wrote: On Mon, Feb 24, 2014 at 07:29:58AM +, Duncan wrote: But I'm still seeing these, albeit less often. Any idea what they could be linked to? (I have a btrs send/receive going right now, it could hanging /mnt/btrfs_pool1 in a way that affects smbd, but the array feels ok otherwise, weird...) [ 1332.548370] INFO: task smbd:21882 blocked for more than 120 seconds. [ 1332.587455] Not tainted 3.13.5-ia32-i915-preempt-20140216 #1 [ 1332.625478] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. I've not seen anything like that here, but there are several kernel 3.13/3.14-rc reports of similar behavior on the list. I'll have to try this. Interestingly, I just got the following overnight. Something killed 3 different drives from software raid arrays, and the drives are all fine. It looks like btrfs hung my kernel hard enough that it messed up software raid, killed my array on which btrfs was, and then caused a cascade of further btrfs failures. Are those 2 traces useful? I upgraded to 3.14rc3 and I'm also seeing hangs, although not as severe To answer earlier questions: 1) the filesystem I'm copying is brand new, I just created it 2) files were contiguous and not being written randomly (mp3s) Here are the logs: [ 381.512765] BTRFS: device label bigbackup devid 3 transid 179 /dev/dm-5 [ 382.875847] BTRFS: device label bigbackup devid 2 transid 179 /dev/dm-6 [ 384.795334] BTRFS: device label bigbackup devid 4 transid 179 /dev/dm-7 [ 387.265961] BTRFS: device label bigbackup devid 5 transid 179 /dev/dm-8 [ 389.904834] BTRFS: device label bigbackup devid 1 transid 179 /dev/dm-9 [ 390.054771] BTRFS: device label bigbackup devid 3 transid 179 /dev/mapper/crypt_sdo1 [ 390.107006] BTRFS: device label bigbackup devid 3 transid 179 /dev/dm-5 [ 390.129071] BTRFS: device label bigbackup devid 2 transid 179 /dev/mapper/crypt_sdn1 [ 390.177737] BTRFS: device label bigbackup devid 2 transid 179 /dev/dm-6 [ 390.221597] BTRFS: device label bigbackup devid 4 transid 179 /dev/mapper/crypt_sdp1 [ 390.291095] BTRFS: device label bigbackup devid 1 transid 179 /dev/mapper/crypt_sdm1 [ 390.334910] BTRFS: device label bigbackup devid 1 transid 179 /dev/dm-9 [ 390.357362] BTRFS: device label bigbackup devid 4 transid 179 /dev/dm-7 [ 390.378629] BTRFS: device label bigbackup devid 5 transid 179 /dev/mapper/crypt_sdq1 [ 390.441157] BTRFS: device label bigbackup devid 1 transid 179 /dev/mapper/crypt_sdm1 [ 390.468279] BTRFS info (device dm-9): disk space caching is enabled [ 390.476577] BTRFS: device label bigbackup devid 5 transid 179 /dev/dm-8 [ 725.501091] INFO: task btrfs-transacti:3218 blocked for more than 120 seconds. [ 725.529118] Not tainted 3.14.0-rc3 #1 [ 725.542713] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 725.567489] btrfs-transacti D 88020d5fa880 0 3218 2 0x [ 725.591645] 88020cad3dc8 0046 88020cad3fd8 88020d5fa350 [ 725.616304] 000141c0 88020d5fa350 8801a5ed82a0 8801a5ed8310 [ 725.640545] 8801a5ed82a0 8801a5ed82a0 88020cad3dd8 [ 725.665227] Call Trace: [ 725.674397] [8160b059] schedule+0x73/0x75 [ 725.690761] [81229973] wait_for_commit.isra.10+0x50/0x67 [ 725.711610] [81085062] ? finish_wait+0x65/0x65 [ 725.729355] [8122acd8] btrfs_commit_transaction+0x143/0x849 [ 725.750238] [81227598] transaction_kthread+0xf8/0x1ab [ 725.769867] [812274a0] ? btrfs_cleanup_transaction+0x43f/0x43f [ 725.791465] [8106bc1b] kthread+0xae/0xb6 [ 725.807384] [8106bb6d] ? __kthread_parkme+0x61/0x61 [ 725.826176] [8161413c] ret_from_fork+0x7c/0xb0 [ 725.843645] [8106bb6d] ? __kthread_parkme+0x61/0x61 [ 845.962068] INFO: task btrfs-transacti:3218 blocked for more than 120 seconds. [ 845.986941] Not tainted 3.14.0-rc3 #1 [ 846.000617] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 846.025730] btrfs-transacti D 88020d5fa880 0 3218 2 0x [ 846.048610] 88020cad3dc8 0046 88020cad3fd8 88020d5fa350 [ 846.072100] 000141c0 88020d5fa350 8801a5ed82a0 8801a5ed8310 [ 846.095559] 8801a5ed82a0 8801a5ed82a0 88020cad3dd8 [ 846.119008] Call Trace: [ 846.127440] [8160b059] schedule+0x73/0x75 [ 846.144015] [81229973] wait_for_commit.isra.10+0x50/0x67 [ 846.164512] [81085062] ? finish_wait+0x65/0x65 [ 846.182412] [8122acd8] btrfs_commit_transaction+0x143/0x849 [ 846.203734] [81227598] transaction_kthread+0xf8/0x1ab [ 846.223484] [812274a0] ? btrfs_cleanup_transaction+0x43f/0x43f [ 846.245587] [8106bc1b] kthread+0xae/0xb6 [ 846.261992]
[PATCH] xfstests: cleanup tests btrfs/004,007,022 and 025
As recently suggested by Dave Chinner, make use of the new function
named _run_btrfs_util_prog() to run the btrfs util program.
Filipe David Borba Manana have cleaned up btrfs/030 and btrfs/034.
I have done the same for the rest ones.
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
tests/btrfs/004 | 2 +-
tests/btrfs/007 | 6 +++---
tests/btrfs/022 | 24
tests/btrfs/025 | 20 ++--
4 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/tests/btrfs/004 b/tests/btrfs/004
index 14da9f1..135f804 100755
--- a/tests/btrfs/004
+++ b/tests/btrfs/004
@@ -182,7 +182,7 @@ workout()
run_check $FSSTRESS_PROG -d $SCRATCH_MNT -w -p $procs -n 2000 \
$FSSTRESS_AVOID
- run_check $BTRFS_UTIL_PROG subvolume snapshot $SCRATCH_MNT \
+ _run_btrfs_util_prog subvolume snapshot $SCRATCH_MNT \
$SCRATCH_MNT/$snap_name
run_check umount $SCRATCH_DEV /dev/null 21
diff --git a/tests/btrfs/007 b/tests/btrfs/007
index 5df9ccb..f022130 100755
--- a/tests/btrfs/007
+++ b/tests/btrfs/007
@@ -74,7 +74,7 @@ workout()
run_check $FSSTRESS_PROG -d $SCRATCH_MNT -n $ops $FSSTRESS_AVOID -x \
$BTRFS_UTIL_PROG subvolume snapshot -r $SCRATCH_MNT
$SCRATCH_MNT/base
- run_check $BTRFS_UTIL_PROG subvolume snapshot -r $SCRATCH_MNT
$SCRATCH_MNT/incr
+ _run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT
$SCRATCH_MNT/incr
echo # $BTRFS_UTIL_PROG send $SCRATCH_MNT/base $tmp/base.snap \
$seqres.full
@@ -97,10 +97,10 @@ workout()
|| _fail size=$fsz mkfs failed
run_check _scratch_mount -o noatime
- run_check $BTRFS_UTIL_PROG receive $SCRATCH_MNT $tmp/base.snap
+ _run_btrfs_util_prog receive $SCRATCH_MNT $tmp/base.snap
run_check $FSSUM_PROG -r $tmp/base.fssum $SCRATCH_MNT/base
- run_check $BTRFS_UTIL_PROG receive $SCRATCH_MNT $tmp/incr.snap
+ _run_btrfs_util_prog receive $SCRATCH_MNT $tmp/incr.snap
run_check $FSSUM_PROG -r $tmp/incr.fssum $SCRATCH_MNT/incr
}
diff --git a/tests/btrfs/022 b/tests/btrfs/022
index ab256a3..16e1ead 100755
--- a/tests/btrfs/022
+++ b/tests/btrfs/022
@@ -49,15 +49,15 @@ rm -f $seqres.full
# Test to make sure we can actually turn it on and it makes sense
_basic_test()
{
- run_check $BTRFS_UTIL_PROG subvolume create $SCRATCH_MNT/a
- run_check $BTRFS_UTIL_PROG quota enable $SCRATCH_MNT/a
+ _run_btrfs_util_prog subvolume create $SCRATCH_MNT/a
+ _run_btrfs_util_prog quota enable $SCRATCH_MNT/a
subvolid=$(_btrfs_get_subvolid $SCRATCH_MNT a)
$BTRFS_UTIL_PROG qgroup show $SCRATCH_MNT | grep $subvolid \
$seqres.full 21
[ $? -eq 0 ] || _fail couldn't find our subvols quota group
run_check $FSSTRESS_PROG -d $SCRATCH_MNT/a -w -p 1 -n 2000 \
$FSSTRESS_AVOID
- run_check $BTRFS_UTIL_PROG subvolume snapshot $SCRATCH_MNT/a \
+ _run_btrfs_util_prog subvolume snapshot $SCRATCH_MNT/a \
$SCRATCH_MNT/b
# the shared values of both the original subvol and snapshot should
@@ -75,8 +75,8 @@ _basic_test()
_rescan_test()
{
# first with a blank subvol
- run_check $BTRFS_UTIL_PROG subvolume create $SCRATCH_MNT/a
- run_check $BTRFS_UTIL_PROG quota enable $SCRATCH_MNT/a
+ _run_btrfs_util_prog subvolume create $SCRATCH_MNT/a
+ _run_btrfs_util_prog quota enable $SCRATCH_MNT/a
subvolid=$(_btrfs_get_subvolid $SCRATCH_MNT a)
run_check $FSSTRESS_PROG -d $SCRATCH_MNT/a -w -p 1 -n 2000 \
$FSSTRESS_AVOID
@@ -85,7 +85,7 @@ _rescan_test()
echo $output $seqres.full
refer=$(echo $output | awk '{ print $2 }')
excl=$(echo $output | awk '{ print $3 }')
- run_check $BTRFS_UTIL_PROG quota rescan -w $SCRATCH_MNT
+ _run_btrfs_util_prog quota rescan -w $SCRATCH_MNT
output=$($BTRFS_UTIL_PROG qgroup show $SCRATCH_MNT | grep $subvolid)
echo $output $seqres.full
[ $refer -eq $(echo $output | awk '{ print $2 }') ] || \
@@ -97,10 +97,10 @@ _rescan_test()
#basic exceed limit testing
_limit_test_exceed()
{
- run_check $BTRFS_UTIL_PROG subvolume create $SCRATCH_MNT/a
- run_check $BTRFS_UTIL_PROG quota enable $SCRATCH_MNT
+ _run_btrfs_util_prog subvolume create $SCRATCH_MNT/a
+ _run_btrfs_util_prog quota enable $SCRATCH_MNT
subvolid=$(_btrfs_get_subvolid $SCRATCH_MNT a)
- run_check $BTRFS_UTIL_PROG qgroup limit 5M 0/$subvolid $SCRATCH_MNT
+ _run_btrfs_util_prog qgroup limit 5M 0/$subvolid $SCRATCH_MNT
dd if=/dev/urandom of=$SCRATCH_MNT/a/file bs=10M count=1 \
$seqres.full 21
[ $? -ne 0 ] || _fail quota should have limited us
@@ -109,10 +109,10 @@ _limit_test_exceed()
#basic noexceed limit testing
_limit_test_noexceed()
{
- run_check $BTRFS_UTIL_PROG subvolume create $SCRATCH_MNT/a
-
3.14.0rc3: did not find backref in send_root
I got this during a btrfs send: BTRFS error (device dm-2): did not find backref in send_root. inode=22672, offset=524288, disk_byte=1490517954560 found extent=1490517954560 I'll try a scrub when I've finished my backup, but is there anything I can run on the file I've found from the inode? gargamel:/mnt/dshelf1/Sound# btrfs inspect-internal inode-resolve -v 22672 file.mp3 ioctl ret=0, bytes_left=3998, bytes_missing=0, cnt=1, missed=0 file.mp3 Anything else? Thanks, Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901 -- 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 userland interface isn't 32/64bit clean (breaks lsattr and btrfs send)
On Mon, Feb 24, 2014 at 08:43:44AM +, Duncan wrote: Hugo Mills posted on Mon, 24 Feb 2014 08:29:38 + as excerpted: On Mon, Feb 24, 2014 at 06:32:14AM +, Duncan wrote: This is a known issue. There's patches in the pipeline for 32-bit userspace on a 64-bit kernel, already. If you mean my recent patch, that's only for receive. I've not noticed any other issues on my 32/64 system, but I've not done much with it either (with btrfs, it's only really used for btrfs receive -- everything else is ext4). Thanks. Yes, I believe that's what I had in mind. So apparently there's more needed. (I /think/ I might have seen at least one additional patch float by for 32/64, but as it's out of my usage domain I'm not paying /that/ much attention to it, so perhaps not.) In the meantime, if that helps someone, on debian it's trivial to get 64bit for some packages. All I had to do was this: gargamel:/usr/src# dpkg --add-architecture amd64 gargamel:/usr/src# dpkg --print-foreign-architectures amd64 gargamel:/usr/src# apt-get install e2fsprogs:amd64 btrfs-tools:amd64 And that's it. Now I'm back in business with a 64bit kernel. Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901 -- 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
Limits of BTRFS_IOC_LOGICAL_INO BTRFS_IOC_INO_PATHS
I was experimenting with the BTRFS_IOC_LOGICAL_INO BTRFS_IOC_INO_PATHS ioctls and noticed that there are some limits in the kernel that limit the number or results they return. For example, for BTRFS_IOC_LOGICAL_INO, the structure that will hold the results can be up to 65536 bytes. Are there any plans to provide an alternative way to access that information without the aforementioned limits? This would be useful, for example, for userspace dedup applications. -- 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: Copyright string update
Fix corporate name for copyright. Signed-off-by: Hidetoshi Seto seto.hideto...@jp.fujitsu.com --- fs/btrfs/delayed-inode.c |2 +- fs/btrfs/delayed-inode.h |2 +- fs/btrfs/math.h |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c index 451b00c..483b918 100644 --- a/fs/btrfs/delayed-inode.c +++ b/fs/btrfs/delayed-inode.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2011 Fujitsu. All rights reserved. + * Copyright (C) 2011 FUJITSU LIMITED. All rights reserved. * Written by Miao Xie mi...@cn.fujitsu.com * * This program is free software; you can redistribute it and/or diff --git a/fs/btrfs/delayed-inode.h b/fs/btrfs/delayed-inode.h index f70119f..a07746d 100644 --- a/fs/btrfs/delayed-inode.h +++ b/fs/btrfs/delayed-inode.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2011 Fujitsu. All rights reserved. + * Copyright (C) 2011 FUJITSU LIMITED. All rights reserved. * Written by Miao Xie mi...@cn.fujitsu.com * * This program is free software; you can redistribute it and/or diff --git a/fs/btrfs/math.h b/fs/btrfs/math.h index b7816ce..1ce7e18 100644 --- a/fs/btrfs/math.h +++ b/fs/btrfs/math.h @@ -1,6 +1,6 @@ /* - * Copyright (C) 2012 Fujitsu. All rights reserved. + * Copyright (C) 2012 FUJITSU LIMITED. All rights reserved. * Written by Miao Xie mi...@cn.fujitsu.com * * This program is free software; you can redistribute it and/or -- 1.7.1 -- 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: 3.14.0rc3: did not find backref in send_root
Hi Marc, This seems a regression which has been fixed by the following commit(only pushed into btrfs-next): https://git.kernel.org/cgit/linux/kernel/git/josef/btrfs-next.git/commit/?id=1334bebe71bebbca47b3b92f25511ea980fdeab8 Thanks, Wang On 02/25/2014 02:36 PM, Marc MERLIN wrote: I got this during a btrfs send: BTRFS error (device dm-2): did not find backref in send_root. inode=22672, offset=524288, disk_byte=1490517954560 found extent=1490517954560 I'll try a scrub when I've finished my backup, but is there anything I can run on the file I've found from the inode? gargamel:/mnt/dshelf1/Sound# btrfs inspect-internal inode-resolve -v 22672 file.mp3 ioctl ret=0, bytes_left=3998, bytes_missing=0, cnt=1, missed=0 file.mp3 Anything else? Thanks, Marc -- 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
