Re: some issues with lots of snapshots
On Fri, Oct 29, 2010 at 00:03, Pat Regan theh...@patshead.com wrote: On Wed, 27 Oct 2010 10:39:48 +0200 Xavier Nicollet nicol...@jeru.org wrote: Le 26 octobre 2010 à 15:15, Pat Regan a écrit: I turned off the 5-minute snapshots and I'm now just keeping 4 weekly, 7 daily, and 24 hourly snapshots alive. I have just rebooted and I am going with /15 minutes interval. I'm just replying so this is documented somewhere. After I read your message I decided to turn on snaphots at 15 minute intervals yesterday. This morning I had snapshot processing filling up my process list again. I think there is no problem with snapshot creation every 5 or 15 minutes, but problem is with deleting old snapshots every 5 or 15 minutes. Can you try to run cleanup of old snapshots only once per day to check if it will improve? My laptop is a quad core i7 and the btrfs file system is on an Intel X25-M 80 gig. I don't know if a fast drives increases or decreases the likelihood of having this problem or not. Pat -- 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 when removing missing drive (Take 2)
So, I ended up just applying the relevant commit to my existing source tree, which did allow me to successfully remove the missing drive, so I seem to be back up and running. Thank you very much! -- Erik On Thu, Oct 28, 2010 at 1:57 PM, Chris Mason chris.ma...@oracle.com wrote: On Tue, Oct 19, 2010 at 07:17:16PM -0700, Erik Jensen wrote: One of my drives on my six drive btrfs setup recently died. I initially wasn't too worried about it, since both my data and metadata are raid1. However, I have so far not been able to remove the missing drive after several attempts. After discussing my problem on IRC, Chris Mason asked me to list everything I've tried on the mailing list, so here goes: Ok, so the current code in the scratch branch is probably going to get rebased. I've got some commits in there to add features to the bdi code, but those features are still being discussed. But, if you: git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git scratch You'll get the scratch branch of the btrfs-unstable repo. It fixes the oops on an unwritable missing drive, which I did reproduce locally. Please let me know how this works -chris 1. I was attempting to cut commercials out of a TV recording when things seemed to stall. A look a dmesg told me that one of my drives was having many read failures. 2. I shut down my computer and removed the failed drive. 3. I booted back up and mounted the array in degraded mode. A quick ls showed all my files. 4. I checked my filesystem usage and concluded that I should have enough free space to build back up to full redundancy on the remaining drives, so I would be protected until my replacement arrived. 5. I executed btrfs-vol -r missing, which churned the hard drives for a little bit and then stalled. dmesg showed this kernel BUG: http://pastebin.com/KgjUUBq0 6. The system wouldn't reboot normally at this point, so I had to use SysRq 7. I temporarily booted a 2.6.35 kernel (I'm currently running 2.6.34) and tried to remove the missing drive again, with the same result. 8. [back on 2.6.34] My replacement drive arrived, so I installed it and added it to the btrfs pool. 9. I tried btrfs-vol -r missing again, and received the same kernel BUG once again. 10. After using SysRq to reboot, I tried doing a btrfs-vol -b, which moved some data around and halted with the same BUG. 11. I checked the kernel source to find why the bug was being thrown. The offending line was BUG_ON(rw == WRITE !dev-writeable); in btrfs_map_bio in volumes.c 12. I used badblocks -nsv to make sure of all my hard drives were writeable, which they were. A paste of all of the logged kernel messages from 8 and 9 is at http://pastebin.org/322902 I would like to get this figured out as quickly as possible, since my data is currently spread across 6 drives with (effectively) no redundancy. I do have C programming experience, so if there is a way that I can help track down the problem, please let me know. Thanks, Erik -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs raid1 degraded does not mount or fsck
kernel: scratch git repo from today 10.29.10 @ 14:30 PST Btrfs v0.19-35-g1b444cd-dirty gypsyops @ /mnt sudo btrfs filesystem show Label: 'das4' uuid: d0e5137f-e5e7-49da-91f6-a9c4e4e72c6f Total devices 3 FS bytes used 1.38TB devid3 size 1.82TB used 0.00 path /dev/sdb devid2 size 1.82TB used 1.38TB path /dev/sdc *** Some devices missing Btrfs v0.19-35-g1b444cd-dirty gypsyops @ /mnt sudo mount -o degraded /dev/sdc das3/ Password: mount: wrong fs type, bad option, bad superblock on /dev/sdc, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so [ 684.577540] device label das4 devid 2 transid 107954 /dev/sdc [ 684.595150] btrfs: allowing degraded mounts [ 684.595594] btrfs: failed to read chunk root on sdb [ 684.604110] btrfs: open_ctree failed gypsyops @ /mnt sudo btrfsck /dev/sdc btrfsck: volumes.c:1367: btrfs_read_sys_array: Assertion `!(ret)' failed. any help please? -- ,-| Vladi `-| Gergov !DSPAM:4ccb39a9191821603519226! -- 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
Blog: BTRFS is effectively stable
A friend of mine who builds storage systems designed for HPC use has been keeping an eye on btrfs and has just done some testing of it with 2.6.36 and seems to like what he sees in terms of stability. http://scalability.org/?p=2711 # But it passed our stability test. 100 iterations (3.2TB # written/read in all and compared to checksums) of the # following fio test case. [...] # This is our baseline test. Failing RAIDs, failing drives, # failing SSDs tend not to pass this test. Borked file systems # tend not to pass this test. When something passes this test, # again and again (3rd time we’ve run it), and does so without # fail, we call it safe. He has concerns about performance, but he's more interested in reliability in these tests. cheers! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
[patch 0/2] Control filesystem balances (kernel side)
These two patches give a degree of control over balance operations. The first makes it possible to get an idea of how much work remains to do, by tracking the number of block groups (chunks) that need to be moved/rewritten. The second patch allows a running balance operation to be cancelled when the current block group has been moved. One fundamental question, though -- is the progress monitor function best implemented as an ioctl, as I've done here, or should it be two or three sysfs files? I'm thinking of /proc/mdstat... Obviously, /proc/mdstat would never get into /sys, but exposing the expected and remaining values as files has an attractive simplicity to it. The user-space side of things are in a separate patch series, to follow. Please be gentle with me, this is my first (serious, non-trivial) kernel patch. :) Hugo. -- === Hugo Mills: h...@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- No! My collection of rare, incurable diseases! Violated! --- -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/2] Balance progress monitoring.
This patch introduces a basic form of progress monitoring for balance
operations, by counting the number of block groups remaining. The
information is exposed to userspace by an ioctl.
Signed-off-by: Hugo Mills h...@carfax.org.uk
---
fs/btrfs/ctree.h |9
fs/btrfs/disk-io.c |2 +
fs/btrfs/ioctl.c | 34
fs/btrfs/ioctl.h |7 ++
fs/btrfs/volumes.c | 55 +++--
5 files changed, 105 insertions(+), 2 deletions(-)
Index: linux-mainline/fs/btrfs/ctree.h
===
--- linux-mainline.orig/fs/btrfs/ctree.h2010-10-26 18:03:38.0
+0100
+++ linux-mainline/fs/btrfs/ctree.h 2010-10-29 17:20:43.860460761 +0100
@@ -803,6 +803,11 @@
struct list_head cluster_list;
};
+struct btrfs_balance_info {
+ u64 expected;
+ u64 completed;
+};
+
struct reloc_control;
struct btrfs_device;
struct btrfs_fs_devices;
@@ -1010,6 +1015,10 @@
unsigned metadata_ratio;
void *bdev_holder;
+
+ /* Keep track of any rebalance operations on this FS */
+ spinlock_t balance_info_lock;
+ struct btrfs_balance_info *balance_info;
};
/*
Index: linux-mainline/fs/btrfs/ioctl.c
===
--- linux-mainline.orig/fs/btrfs/ioctl.c2010-10-26 18:03:38.0
+0100
+++ linux-mainline/fs/btrfs/ioctl.c 2010-10-29 17:21:26.128742389 +0100
@@ -1984,6 +1984,38 @@
return 0;
}
+/*
+ * Return the current status of any balance operation
+ */
+long btrfs_ioctl_balance_progress(
+ struct btrfs_fs_info *fs_info,
+ struct btrfs_ioctl_balance_progress __user *user_dest)
+{
+ int ret = 0;
+ struct btrfs_ioctl_balance_progress dest;
+
+ spin_lock(fs_info-balance_info_lock);
+ if (!fs_info-balance_info) {
+ ret = -EINVAL;
+ goto error;
+ }
+
+ dest.expected = fs_info-balance_info-expected;
+ dest.completed = fs_info-balance_info-completed;
+
+ spin_unlock(fs_info-balance_info_lock);
+
+ if (copy_to_user(user_dest, dest,
+sizeof(struct btrfs_ioctl_balance_progress)))
+ return -EFAULT;
+
+ return 0;
+
+error:
+ spin_unlock(fs_info-balance_info_lock);
+ return ret;
+}
+
long btrfs_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
{
@@ -2017,6 +2049,8 @@
return btrfs_ioctl_rm_dev(root, argp);
case BTRFS_IOC_BALANCE:
return btrfs_balance(root-fs_info-dev_root);
+ case BTRFS_IOC_BALANCE_PROGRESS:
+ return btrfs_ioctl_balance_progress(root-fs_info, argp);
case BTRFS_IOC_CLONE:
return btrfs_ioctl_clone(file, arg, 0, 0, 0);
case BTRFS_IOC_CLONE_RANGE:
Index: linux-mainline/fs/btrfs/ioctl.h
===
--- linux-mainline.orig/fs/btrfs/ioctl.h2010-10-26 18:03:38.0
+0100
+++ linux-mainline/fs/btrfs/ioctl.h 2010-10-29 17:05:44.447028825 +0100
@@ -138,6 +138,11 @@
struct btrfs_ioctl_space_info spaces[0];
};
+struct btrfs_ioctl_balance_progress {
+ __u64 expected;
+ __u64 completed;
+};
+
#define BTRFS_IOC_SNAP_CREATE _IOW(BTRFS_IOCTL_MAGIC, 1, \
struct btrfs_ioctl_vol_args)
#define BTRFS_IOC_DEFRAG _IOW(BTRFS_IOCTL_MAGIC, 2, \
@@ -178,4 +183,6 @@
#define BTRFS_IOC_DEFAULT_SUBVOL _IOW(BTRFS_IOCTL_MAGIC, 19, u64)
#define BTRFS_IOC_SPACE_INFO _IOWR(BTRFS_IOCTL_MAGIC, 20, \
struct btrfs_ioctl_space_args)
+#define BTRFS_IOC_BALANCE_PROGRESS _IOR(BTRFS_IOCTL_MAGIC, 21, \
+ struct btrfs_ioctl_balance_progress)
#endif
Index: linux-mainline/fs/btrfs/volumes.c
===
--- linux-mainline.orig/fs/btrfs/volumes.c 2010-10-26 18:03:38.0
+0100
+++ linux-mainline/fs/btrfs/volumes.c 2010-10-29 17:23:40.463279287 +0100
@@ -1902,6 +1902,7 @@
struct btrfs_root *chunk_root = dev_root-fs_info-chunk_root;
struct btrfs_trans_handle *trans;
struct btrfs_key found_key;
+ struct btrfs_balance_status *bal_info;
if (dev_root-fs_info-sb-s_flags MS_RDONLY)
return -EROFS;
@@ -1909,6 +1910,18 @@
mutex_lock(dev_root-fs_info-volume_mutex);
dev_root = dev_root-fs_info-dev_root;
+ dev_root-fs_info-balance_info = kmalloc(
+ sizeof(struct btrfs_balance_info),
+ GFP_NOFS);
+ if (!dev_root-fs_info-balance_info) {
+ ret = -ENOSPC;
+ goto error_no_status;
+ }
+ bal_info = dev_root-fs_info-balance_info;
+ bal_info-expected = -1; /* One less than actually counted,
+
[patch 2/2] Cancel filesystem balance.
This patch adds an ioctl for cancelling a btrfs balance operation
mid-flight. The ioctl simply sets a flag, and the operation terminates
after the current block group move has completed.
Signed-off-by: Hugo Mills h...@carfax.org.uk
---
fs/btrfs/ctree.h |1 +
fs/btrfs/ioctl.c | 25 +
fs/btrfs/ioctl.h |1 +
fs/btrfs/volumes.c |7 ++-
4 files changed, 33 insertions(+), 1 deletion(-)
Index: linux-mainline/fs/btrfs/ctree.h
===
--- linux-mainline.orig/fs/btrfs/ctree.h2010-10-29 17:20:43.860460761
+0100
+++ linux-mainline/fs/btrfs/ctree.h 2010-10-29 17:24:06.622214467 +0100
@@ -806,6 +806,7 @@
struct btrfs_balance_info {
u64 expected;
u64 completed;
+ int cancel_pending;
};
struct reloc_control;
Index: linux-mainline/fs/btrfs/ioctl.c
===
--- linux-mainline.orig/fs/btrfs/ioctl.c2010-10-29 17:21:26.128742389
+0100
+++ linux-mainline/fs/btrfs/ioctl.c 2010-10-29 17:27:51.933043374 +0100
@@ -2016,6 +2016,29 @@
return ret;
}
+/*
+ * Cancel a running balance operation
+ */
+long btrfs_ioctl_balance_cancel(struct btrfs_fs_info *fs_info)
+{
+ int err = 0;
+
+ spin_lock(fs_info-balance_info_lock);
+ if(!fs_info-balance_info) {
+ err = -EINVAL;
+ goto error;
+ }
+ if(fs_info-balance_info-cancel_pending) {
+ err = -ECANCELED;
+ goto error;
+ }
+ fs_info-balance_info-cancel_pending = 1;
+
+error:
+ spin_unlock(fs_info-balance_info_lock);
+ return err;
+}
+
long btrfs_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
{
@@ -2051,6 +2074,8 @@
return btrfs_balance(root-fs_info-dev_root);
case BTRFS_IOC_BALANCE_PROGRESS:
return btrfs_ioctl_balance_progress(root-fs_info, argp);
+ case BTRFS_IOC_BALANCE_CANCEL:
+ return btrfs_ioctl_balance_cancel(root-fs_info);
case BTRFS_IOC_CLONE:
return btrfs_ioctl_clone(file, arg, 0, 0, 0);
case BTRFS_IOC_CLONE_RANGE:
Index: linux-mainline/fs/btrfs/ioctl.h
===
--- linux-mainline.orig/fs/btrfs/ioctl.h2010-10-29 17:05:44.447028825
+0100
+++ linux-mainline/fs/btrfs/ioctl.h 2010-10-29 17:24:06.642213653 +0100
@@ -185,4 +185,5 @@
struct btrfs_ioctl_space_args)
#define BTRFS_IOC_BALANCE_PROGRESS _IOR(BTRFS_IOCTL_MAGIC, 21, \
struct btrfs_ioctl_balance_progress)
+#define BTRFS_IOC_BALANCE_CANCEL _IO(BTRFS_IOCTL_MAGIC, 22)
#endif
Index: linux-mainline/fs/btrfs/volumes.c
===
--- linux-mainline.orig/fs/btrfs/volumes.c 2010-10-29 17:23:40.463279287
+0100
+++ linux-mainline/fs/btrfs/volumes.c 2010-10-29 17:24:06.652213246 +0100
@@ -1921,6 +1921,7 @@
bal_info-expected = -1; /* One less than actually counted,
because chunk 0 is special */
bal_info-completed = 0;
+ bal_info-cancel_pending = 0;
/* step one make some room on all the devices */
list_for_each_entry(device, devices, dev_list) {
@@ -1983,7 +1984,7 @@
key.offset = (u64)-1;
key.type = BTRFS_CHUNK_ITEM_KEY;
- while (1) {
+ while (!bal_info-cancel_pending) {
ret = btrfs_search_slot(NULL, chunk_root, key, path, 0, 0);
if (ret 0)
goto error;
@@ -2024,6 +2025,10 @@
bal_info-completed, bal_info-expected);
}
ret = 0;
+ if(bal_info-cancel_pending) {
+ printk(KERN_INFO btrfs: balance cancelled\n);
+ ret = -EINTR;
+ }
error:
btrfs_free_path(path);
spin_lock(dev_root-fs_info-balance_info_lock);
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 0/2] Control filesystem balances (userspace)
These two patches complement the previous two kernel-side patches. The first implements a way of displaying the current progress of any running balance process. The second patch allows a running balance to be cancelled. I'm a bit uncertain about the best name for these commands. Several options: 1) # btrfs filesystem progress path # btrfs filesystem cancel path Way too vague (cancel *what*?) 2) # btrfs filesystem balance-progress path # btrfs filesystem balance-cancel path Clashes horribly with filesystem balance -- no abbreviations possible. 3) btrfs filesystem balance -p path btrfs filesystem balance -c path Changes behaviour significantly on a switch, in contrast to the behaviour of the rest of the btrfs tool. 4) btrfs balance progress path btrfs balance cancel path My current favourite, although we introduce a new namespace (balance) for commands. We could add btrfs balance start path as a synonym for btrfs filesystem balance path, for some degree of consistency. At some point, I'll add a monitor function, which will poll at 1s intervals for progress updates, and print out progress when it changes. Hugo. -- === Hugo Mills: h...@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- No! My collection of rare, incurable diseases! Violated! --- -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/2] User-space tool for cancelling balance operations.
Add an option to the btrfs tool to use the ioctl for cancelling
balance operations.
SIgned-off-by: Hugo Mills h...@carfax.org.uk
---
btrfs.c |4
btrfs_cmds.c | 41 +
btrfs_cmds.h |1 +
ioctl.h |1 +
4 files changed, 47 insertions(+)
Index: btrfs-progs-unstable/btrfs.c
===
--- btrfs-progs-unstable.orig/btrfs.c 2010-10-30 00:19:59.968416575 +0100
+++ btrfs-progs-unstable/btrfs.c2010-10-30 00:20:38.446849736 +0100
@@ -99,6 +99,10 @@
balance progress, path\n
Show progress of the balance operation running on path.
},
+ { do_balance_cancel, 1,
+ balance cancel, path\n
+ Cancel the balance operation running on path.
+ },
{ do_scan,
999, device scan, [device [device..]\n
Scan all device for or the passed device for a btrfs\n
Index: btrfs-progs-unstable/btrfs_cmds.c
===
--- btrfs-progs-unstable.orig/btrfs_cmds.c 2010-10-30 00:04:48.335524683
+0100
+++ btrfs-progs-unstable/btrfs_cmds.c 2010-10-30 00:20:22.267508562 +0100
@@ -848,6 +848,47 @@
return 0;
}
+int do_balance_cancel(int nargs, char **argv)
+{
+ char *path = argv[1];
+ int fdmnt;
+ int ret = 0;
+ int err = 0;
+
+ fdmnt = open_file_or_dir(path);
+ if(fdmnt 0) {
+ fprintf(stderr, ERROR: can't access '%s'\n, path);
+ return 12;
+ }
+
+ ret = ioctl(fdmnt, BTRFS_IOC_BALANCE_CANCEL, NULL);
+ err = errno;
+
+ if(ret) {
+ switch(err) {
+ case 0:
+ break;
+ case EINVAL:
+ fprintf(stderr, ERROR: no balance in progress.\n);
+ err = 20;
+ break;
+ case ECANCELED:
+ fprintf(stderr, ERROR: operation already
cancelled.\n);
+ err = 21;
+ break;
+ default:
+ fprintf(stderr, ERROR: ioctl returned error '%d'.\n,
+ err);
+ err = 22;
+ break;
+ }
+ }
+
+ close(fdmnt);
+
+ return err;
+}
+
int do_remove_volume(int nargs, char **args)
{
Index: btrfs-progs-unstable/btrfs_cmds.h
===
--- btrfs-progs-unstable.orig/btrfs_cmds.h 2010-10-30 00:04:48.335524683
+0100
+++ btrfs-progs-unstable/btrfs_cmds.h 2010-10-30 00:20:22.307506934 +0100
@@ -24,6 +24,7 @@
int do_add_volume(int nargs, char **args);
int do_balance(int nargs, char **argv);
int do_balance_progress(int nargs, char **argv);
+int do_balance_cancel(int nargs, char **argv);
int do_remove_volume(int nargs, char **args);
int do_scan(int nargs, char **argv);
int do_resize(int nargs, char **argv);
Index: btrfs-progs-unstable/ioctl.h
===
--- btrfs-progs-unstable.orig/ioctl.h 2010-10-30 00:04:48.325525089 +0100
+++ btrfs-progs-unstable/ioctl.h2010-10-30 00:20:22.357504895 +0100
@@ -176,4 +176,5 @@
struct btrfs_ioctl_space_args)
#define BTRFS_IOC_BALANCE_PROGRESS _IOR(BTRFS_IOCTL_MAGIC, 21, \
struct btrfs_ioctl_balance_progress)
+#define BTRFS_IOC_BALANCE_CANCEL _IO(BTRFS_IOCTL_MAGIC, 22)
#endif
--
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: Blog: BTRFS is effectively stable
Hi, A friend of mine who builds storage systems designed for HPC use has been keeping an eye on btrfs and has just done some testing of it with 2.6.36 and seems to like what he sees in terms of stability. http://scalability.org/?p=2711 This is nice to see, but we should be clearer about what stability means. This was just fio testing; it doesn't say anything about resilience to crashes, power offs, or the presence of corruption. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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
