Re: [patch 1/2] Balance progress monitoring (updated)
On 10/30/2010 09:39 PM, Hugo Mills wrote:
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.
IMO, tracking the information of blocks which are balancing also makes sense.
For example, the block information's blocknr.
It can help us monitor better.
Signed-off-by: Hugo Mills h...@carfax.org.uk
---
This patch replaces the one previously posted, correcting a minor error.
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.h 2010-10-26 18:03:38.0
+0100
+++ linux-mainline/fs/btrfs/ctree.h 2010-10-30 14:35:25.306450922 +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.c 2010-10-26 18:03:38.0
+0100
+++ linux-mainline/fs/btrfs/ioctl.c 2010-10-30 14:35:25.396447198 +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.h 2010-10-26 18:03:38.0
+0100
+++ linux-mainline/fs/btrfs/ioctl.h 2010-10-30 14:35:25.316450509 +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.c2010-10-26 18:03:38.0
+0100
+++ linux-mainline/fs/btrfs/volumes.c 2010-10-30 14:35:25.326450096 +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_info *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),
+
Re: btrfs and apt package manager in ubuntu
On Sun, Oct 31, 2010 at 11:21:36AM -0500, Christian wrote: On Sun, 2010-10-31 at 16:17 +0300, Abdullah Ansari wrote: it's very slow in installtion with apt in ubuntu I'm seeing the same thing. When installing using apt the disk grinds forever before the installation completes. I have two identical laptops running Linux Mint 10 (rc) with similar disk layout except that one has two btrfs partitions while the other only has ext4. The one with btrfs takes at least 10 times longer to install updates on than the ext4 one. That's because dpkg uses sync when unpacking each package. 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: btrfs-convert fails
Hallo, Yan, Du meintest am 01.11.10: I've tried to convert a 12 GByte ext2 partition (nearly full, 280 MByte free) with btrfs-convert. After about 15 minutes (700-MHz-CPU) the system tells ... creating ext2fs image file cleaning up system chunk btrfs-convert: extent-tree.c:2529: btrfs_reserve_extent: Assertion `!(ret)' failed Abgebrochen Try btrfs-convert -r /dev/xxx, hopefully it will recover your ext2. Restoring is (now) no problem, I'm still testing. But in some days (or weeks) I want to convert a partition with 1,5 TByte (which has no backup) ... Viele Gruesse! Helmut -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
How to see raid level?!
Hi, I saw some reports of ppl in this list who did a btrfs fi df /path and saw the raidlevel of the data, metadata etc. How? :) I'm using the git version of the btrfs progs and 2.6.36, but I don't see those informations. Btrfs v0.19-35-g1b444cd-dirty What am I doing wrong? :( Regards, Felix -- 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 see raid level?!
On Mon, Nov 1, 2010 at 4:17 AM, Felix Blanke felixbla...@gmail.com wrote: Hi, I saw some reports of ppl in this list who did a btrfs fi df /path and saw the raidlevel of the data, metadata etc. How? :) I'm using the git version of the btrfs progs and 2.6.36, but I don't see those informations. Btrfs v0.19-35-g1b444cd-dirty What am I doing wrong? :( You didn't include the magic patch. :p Raid level reporting was broken for a while, josef sent some patches recently that fixed it, which I saw in cmason's pull request for 2.6.37. -- 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 2.6.36 btrfs csum bugreport
To follow up on this matter, I have created another two btrfs volumes (also plain - no options - also on two external USB-SATA disks), and am at the moment copying heaps of data between these two. No errors as of yet. All copies are verified by md5sum after the deed. The volume in question can still reliably reproduce the csum errors on read, though. Aprox. 30 csum errors occur when the whole fs is read. The data is still fine. I can put it aside for further debugging until at most Wednesday morning. If someone wants me to run diagnostics on it, please let me know. I am glad to be of help (until Wednesday morning). Andreas -- 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 2.6.36 btrfs csum bugreport
On 1 November 2010 00:35, Andreas Bauer a...@voltage.de wrote: So I conclude that these messages are faulty because data is read correctly. In addition, when you have more than one btrfs you cannot see from the message which fs it is refering to. Is this a raid1 or a dup array? No, plain vanilla partition on physical hard disk. Btrfs was made with the command mkfs.btrfs /dev/sdc1 no extra arguments. By default, metadata is duplicated, thus it could be that BTRFS is using the correct copy of the metadata after finding checksum errors in the first copy. Daniel -- Daniel J Blueman -- 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 2.6.36 btrfs csum bugreport
On Mon, Nov 1, 2010 at 4:55 AM, Daniel J Blueman daniel.blue...@gmail.com wrote: On 1 November 2010 00:35, Andreas Bauer a...@voltage.de wrote: So I conclude that these messages are faulty because data is read correctly. In addition, when you have more than one btrfs you cannot see from the message which fs it is refering to. Is this a raid1 or a dup array? No, plain vanilla partition on physical hard disk. Btrfs was made with the command mkfs.btrfs /dev/sdc1 no extra arguments. By default, metadata is duplicated, thus it could be that BTRFS is using the correct copy of the metadata after finding checksum errors in the first copy. Ahhh, and that makes this make sense: Andreas, have you checked which file(s) are giving the errors? if not, you can use find /whatever/mountpoint -xdev -inum 5098 -print to get the filename. And I would bet that it's small enough that it's being inlined into the metadata block group, and therefore covered under the default dup profile of that block group, which is why you're getting the actual file data back. -- 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-convert fails
Hallo, Felix, Du meintest am 01.11.10: btrfs-convert: extent-tree.c:2529: btrfs_reserve_extent: Assertion `!(ret)' failed Abgebrochen Try btrfs-convert -r /dev/xxx, hopefully it will recover your ext2. Restoring is (now) no problem, I'm still testing. But in some days (or weeks) I want to convert a partition with 1,5 TByte (which has no backup) ... don't use btrfs for important files if you got no backup yet. It's quite stable and a lot of ppl don't have problem with it, but there are some cases where it could be very ugly, like a powerloss while writing etc. In these special cases: no big problem. The 1.5 TByte partition contains my videos (at least most of them), and there is a kind of backup on another machine in the family (some kilometers away). And my machine works behind an UPS. But what about a shutdown initiated by this UPS after (p.e.) 3 minutes powerloss? Viele Gruesse! Helmut -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to see raid level?!
Ah, the magic one :) Is that a patch for the kernel or the btrfs progs? If you know where to get that patch it would be nice. It isn't an important issue but it would be nice to see if my home really uses raid1 for data :) Regards, FElix On 01. November 2010 - 04:33, cwillu wrote: Date: Mon, 1 Nov 2010 04:33:30 -0600 From: cwillu cwi...@cwillu.com To: Felix Blanke felixbla...@gmail.com Cc: linux-btrfs@vger.kernel.org Subject: Re: How to see raid level?! On Mon, Nov 1, 2010 at 4:17 AM, Felix Blanke felixbla...@gmail.com wrote: Hi, I saw some reports of ppl in this list who did a btrfs fi df /path and saw the raidlevel of the data, metadata etc. How? :) I'm using the git version of the btrfs progs and 2.6.36, but I don't see those informations. Btrfs v0.19-35-g1b444cd-dirty What am I doing wrong? :( You didn't include the magic patch. :p Raid level reporting was broken for a while, josef sent some patches recently that fixed it, which I saw in cmason's pull request for 2.6.37. ---end quoted text--- -- 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 see raid level?!
On Mon, Nov 1, 2010 at 6:14 AM, Felix Blanke felixbla...@gmail.com wrote: Ah, the magic one :) Is that a patch for the kernel or the btrfs progs? If you know where to get that patch it would be nice. It isn't an important issue but it would be nice to see if my home really uses raid1 for data :) Kernel patch; c9996a22 Btrfs: fix the df ioctl to report raid types -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/2] Control filesystem balances (kernel side)
Le 30 octobre 2010 à 19:44, Goffredo Baroncelli a écrit: I like the idea that these info should be put under sysfs. Something like /sys/btrfs/filesystem-uuid/ balance - info on balancing devices - list of device (a directory of links or a file which contains the list of devices) subvolumes/ - info on subvolume(s) label - label of the filesystem other btrfs filesystem related knoba Well, mdstat stats are under /proc/mdstat. Is sysfs the ideal place ? Just asking. -- Xavier Nicollet -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/2] Control filesystem balances (kernel side)
On Mon, Nov 01, 2010 at 01:58:21PM +0100, Xavier Nicollet wrote: Le 30 octobre 2010 à 19:44, Goffredo Baroncelli a écrit: I like the idea that these info should be put under sysfs. Something like /sys/btrfs/filesystem-uuid/ balance- info on balancing devices- list of device (a directory of links or a file which contains the list of devices) subvolumes/ - info on subvolume(s) label - label of the filesystem other btrfs filesystem related knoba Well, mdstat stats are under /proc/mdstat. Is sysfs the ideal place ? mdstats are in sys: /sys/block/md127/md/ sync_action, sync_completed, sync_speed, reshape_position etc. /proc file is legacy. -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray -- 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 1/2] Balance progress monitoring (updated)
On Mon, Nov 01, 2010 at 04:06:53PM +0800, liubo wrote: On 10/30/2010 09:39 PM, Hugo Mills wrote: 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. IMO, tracking the information of blocks which are balancing also makes sense. For example, the block information's blocknr. It can help us monitor better. I don't see how that will help. The block group IDs (which is all that we get at this level) are effectively arbitrary 64-bit numbers, and are what appear in the kernel logs. How could that information be used to improve monitoring? I'm not ruling out the idea completely -- I just can't see at the moment how it would be used. 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 --- Is a diversity twice as good as a university? --- signature.asc Description: Digital signature
Re: [patch 0/2] Control filesystem balances (kernel side)
On Sat, Oct 30, 2010 at 07:44:35PM +0200, Goffredo Baroncelli wrote: On Saturday, 30 October, 2010, Hugo Mills wrote: 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. I like the idea that these info should be put under sysfs. Something like /sys/btrfs/filesystem-uuid/ /sys/fs/btrfs/uuid I think. Also: /sys/fs/btrfs/label as a symlink to the uuid directory. balance - info on balancing For the one-value-per-file rule of sysfs, this should probably be balance_expected and balance_completed, each holding a count of block groups. devices - list of device (a directory of links or a file which contains the list of devices) subvolumes/ - info on subvolume(s) label - label of the filesystem other btrfs filesystem related knoba The other one that struck me earlier today as being useful was tracking the progress of a dev delete operation. But that'll come later. Obviously we need another btrfs command to extract an uuid from a btrfs filesystem like: # btrfs filesystem get-uuid /path/to/a/btrfs/filesystem f9b9c413-0dc8-4e3f-94f2-86faa702f519 Possibly a slightly more general fi metadata with switches for UUID and label? # btrfs fi metadata [-u|--uuid] /path # btrfs fi metadata [-l|--label] /path 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 --- Is a diversity twice as good as a university? --- signature.asc Description: Digital signature
btrfs benchmark with 2.6.37-rc1
Here is a small btrfs vs. ext4 benchmark with kernel 2.6.37-rc1. compilebench with options -i 10 -r 30 on 2.6.37-rc1 btrfs == intial create total runs 10 avg 73.11 MB/s (user 0.34s sys 1.96s) create total runs 5 avg 49.53 MB/s (user 0.41s sys 1.62s) patch total runs 4 avg 22.13 MB/s (user 0.09s sys 1.79s) compile total runs 7 avg 104.55 MB/s (user 0.08s sys 1.02s) clean total runs 4 avg 564.00 MB/s (user 0.01s sys 0.28s) read tree total runs 2 avg 29.62 MB/s (user 0.00s sys 2.77s) read compiled tree total runs 1 avg 31.85 MB/s (user 0.00s sys 5.03s) delete tree total runs 2 avg 4.06 seconds (user 0.11s sys 1.92s) no runs for delete compiled tree stat tree total runs 4 avg 2.79 seconds (user 0.07s sys 0.79s) stat compiled tree total runs 1 avg 2.50 seconds (user 0.10s sys 0.80s) ext4 == intial create total runs 10 avg 120.03 MB/s (user 0.34s sys 1.31s) create total runs 5 avg 69.70 MB/s (user 0.44s sys 1.09s) patch total runs 4 avg 30.45 MB/s (user 0.05s sys 1.43s) compile total runs 7 avg 120.22 MB/s (user 0.07s sys 1.03s) clean total runs 4 avg 1199.56 MB/s (user 0.01s sys 0.10s) read tree total runs 2 avg 49.29 MB/s (user 0.03s sys 2.29s) read compiled tree total runs 1 avg 51.73 MB/s (user 0.04s sys 4.74s) delete tree total runs 2 avg 1.13 seconds (user 0.06s sys 0.68s) no runs for delete compiled tree stat tree total runs 4 avg 0.83 seconds (user 0.05s sys 0.44s) stat compiled tree total runs 1 avg 0.82 seconds (user 0.06s sys 0.45s) Best regards, Morten -- 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 benchmark with 2.6.37-rc1
2010/11/1 cwillu cwi...@cwillu.com: Can you include the mkfs and mount options in use? mkfs.btrfs /dev/sdb mount -t btrfs /dev/sdb /mnt/btrfs and for ext4: mkfs.ext4 /dev/sdb mount -t ext4 /dev/sdb/ mnt/btrfs Best regards, Morten -- 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: Horrible btrfs performance due to fragmentation
On Mon, Nov 1, 2010 at 12:47 AM, Hugo Mills hugo-l...@carfax.org.uk wrote: On Mon, Nov 01, 2010 at 12:36:58AM +0200, Felipe Contreras wrote: On Mon, Nov 1, 2010 at 12:25 AM, cwillu cwi...@cwillu.com wrote: btrfs fi defrag isn't recursive. btrfs filesystem defrag /home will defragment the space used to store the folder, without touching the space used to store files in that folder. Yes, that came up on the IRC, but: 1) It doesn't make sense: btrfs filesystem doesn't allow a fileystem as argument? Why would anyone want it to be _non_ recursive? You missed the subsequent discussion on IRC about the interaction of COW with defrag. Essentially, if you've got two files that are COW copies of each other, and one has had something written to it since, it's *impossible* for both files to be defragmented, without making a full copy of both: Start with a file (A, etc are data blocks on the disk): file1 = ABCDEF Cow copy it: file1 = ABCDEF file2 = ABCDEF Now write to one of them: file1 = ABCDEF file2 = ABCDxF So, either file1 is contiguous, and file2 is fragmented (with the block x somewhere else on disk), or file2 is contiguous, and file1 is fragmented (with E somewhere else on disk). In fact, we've determined by experiment that when you defrag a file that's sharing blocks with another one, the file gets copied in its entirety, thus separating the blocks of the file and its COW duplicate. Ok, but the fragmentation would not be an issue in this case. 2) The filesystem should not degrade performance so horribly no matter how long the it has been used. Even git has automatic garbage collection. Since, I believe, btrfs uses COW very heavily internally for ensuring consistency, you can end up with fragmenting files and directories very easily. You probably need some kind of scrubber that goes looking for non-COW files that are fragmented, and defrags them in the background. Or when going through all the fragments of a file, have a counter, and if it exceeds certain limit mark it somehow, so that it gets defragmented at least to a certain extent. -- Felipe Contreras -- 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: Horrible btrfs performance due to fragmentation
On Mon, Nov 1, 2010 at 11:58 AM, Felipe Contreras felipe.contre...@gmail.com wrote: Or when going through all the fragments of a file, have a counter, and if it exceeds certain limit mark it somehow, so that it gets defragmented at least to a certain extent. Thats elegant, — then resources are only spent on defragmenting files which are actually in use and which actually need it... but I don't see how it deals with the partial mutual exclusivity of defragmenting and COWed files. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] btrfs: implement 'async-snapshot' command
On Sat, 30 Oct 2010, Goffredo Baroncelli wrote:
On Saturday, 30 October, 2010, Sage Weil wrote:
This is identical to 'snapshot', but uses the new async snapshot creation
ioctl, and prints out the transid the new snapshot will be committed
with.
Signed-off-by: Sage Weil s...@newdream.net
---
btrfs.c |8 +++-
btrfs_cmds.c | 32 +++-
btrfs_cmds.h |3 ++-
3 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/btrfs.c b/btrfs.c
index 46314cf..c4b9a31 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -44,11 +44,17 @@ static struct Command commands[] = {
/*
avoid short commands different for the case only
*/
- { do_clone, 2,
+ { do_create_snap, 2,
subvolume snapshot, source [dest/]name\n
Create a writable snapshot of the subvolume source with\n
the name name in the dest directory.
},
+ { do_create_snap_async, 2,
+ subvolume async-snapshot, source [dest/]name\n
+ Create a writable snapshot of the subvolume source with\n
+ the name name in the dest directory. Do not wait for\n
+ the snapshot creation to commit to disk before returning.
+ },
Why create another command ? I think that it is better add a switch like
btrfs subvolume snapshot [--async] source [dest/]name
How about
btrfs subvolume snapshot source [dest/]name [async]
That avoids ambiguity when source is named '--async' and simplifies
parsing. Updated patches follow (including man page updates).
sage
Create a writable snapshot of the subvolume source with
the name name in the dest directory. If --async is
passed, do not wait for the snapshot creation to commit to
disk before returning.
In any case, please update the man page too.
{ do_delete_subvolume, 1,
subvolume delete, subvolume\n
Delete the subvolume subvolume.
diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index 8031c58..6da5862 100644
--- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -307,7 +307,7 @@ int do_subvol_list(int argc, char **argv)
return 0;
}
-int do_clone(int argc, char **argv)
+static int create_snap(int argc, char **argv, int async)
{
char*subvol, *dst;
int res, fd, fddst, len;
@@ -316,7 +316,6 @@ int do_clone(int argc, char **argv)
subvol = argv[1];
dst = argv[2];
- struct btrfs_ioctl_vol_args args;
res = test_issubvolume(subvol);
if(res0){
@@ -374,9 +373,22 @@ int do_clone(int argc, char **argv)
printf(Create a snapshot of '%s' in '%s/%s'\n,
subvol, dstdir, newname);
- args.fd = fd;
- strcpy(args.name, newname);
- res = ioctl(fddst, BTRFS_IOC_SNAP_CREATE, args);
+ if (async) {
+ struct btrfs_ioctl_async_vol_args async_args;
+ async_args.fd = fd;
+ async_args.transid = 0;
+ strcpy(async_args.name, newname);
+ res = ioctl(fddst, BTRFS_IOC_SNAP_CREATE_ASYNC, async_args);
+ if (res == 0)
+ printf(transid %llu\n,
+ (unsigned long long)async_args.transid);
+ } else {
+ struct btrfs_ioctl_vol_args args;
+
+ args.fd = fd;
+ strcpy(args.name, newname);
+ res = ioctl(fddst, BTRFS_IOC_SNAP_CREATE, args);
+ }
close(fd);
close(fddst);
@@ -390,6 +402,16 @@ int do_clone(int argc, char **argv)
}
+int do_create_snap_async(int argc, char **argv)
+{
+ return create_snap(argc, argv, 1);
+}
+
+int do_create_snap(int argc, char **argv)
+{
+ return create_snap(argc, argv, 0);
+}
+
int do_delete_subvolume(int argc, char **argv)
{
int res, fd, len;
diff --git a/btrfs_cmds.h b/btrfs_cmds.h
index 7bde191..c44dc79 100644
--- a/btrfs_cmds.h
+++ b/btrfs_cmds.h
@@ -15,7 +15,8 @@
*/
/* btrfs_cmds.c*/
-int do_clone(int nargs, char **argv);
+int do_create_snap(int nargs, char **argv);
+int do_create_snap_async(int nargs, char **argv);
int do_delete_subvolume(int nargs, char **argv);
int do_create_subvol(int nargs, char **argv);
int do_fssync(int nargs, char **argv);
--
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
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
--
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
[PATCH] btrfs-progs: ioctl: add may_alias to btrfs_ioctl_search_header
This fixes the errors
btrfs-list.c: In function 'ino_resolve':
btrfs-list.c:506: error: dereferencing pointer 'sh' does break strict-aliasing
rules
btrfs-list.c:504: error: dereferencing pointer 'sh' does break strict-aliasing
rules
btrfs-list.c:502: note: initialized from here
when building with gcc version 4.4.4 (Debian 4.4.4-6).
Signed-off-by: Sage Weil s...@newdream.net
---
ioctl.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ioctl.h b/ioctl.h
index 5a03317..4a850ff 100644
--- a/ioctl.h
+++ b/ioctl.h
@@ -87,7 +87,7 @@ struct btrfs_ioctl_search_header {
__u64 offset;
__u32 type;
__u32 len;
-};
+} __attribute__((__may_alias__));
#define BTRFS_SEARCH_ARGS_BUFSIZE (4096 - sizeof(struct
btrfs_ioctl_search_key))
/*
--
1.7.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
[PATCH v2] btrfs-progs: btrfs: implement async option for snapshot command
Add an 'async' option to the snapshot creating command, that will let you
avoid waiting for a new snapshot to commit to disk.
Signed-off-by: Sage Weil s...@newdream.net
---
btrfs.c|9 ++---
btrfs_cmds.c | 31 +--
btrfs_cmds.h |2 +-
man/btrfs.8.in | 15 ++-
4 files changed, 42 insertions(+), 15 deletions(-)
diff --git a/btrfs.c b/btrfs.c
index c871f4a..657bb6f 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -44,10 +44,13 @@ static struct Command commands[] = {
/*
avoid short commands different for the case only
*/
- { do_clone, 2,
- subvolume snapshot, source [dest/]name\n
+ { do_create_snap, -2,
+ subvolume snapshot, source [dest/]name [async]\n
Create a writable snapshot of the subvolume source with\n
- the name name in the dest directory.
+ the name name in the dest directory. If [async] is\n
+ specified, we will not wait for the snapshot to be committed\n
+ to disk, and a transid will be printed that can be fed to\n
+ 'filesystem wait-sync transid'.
},
{ do_delete_subvolume, 1,
subvolume delete, subvolume\n
diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index 736437d..276b8fa 100644
--- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -307,16 +307,22 @@ int do_subvol_list(int argc, char **argv)
return 0;
}
-int do_clone(int argc, char **argv)
+int do_create_snap(int argc, char **argv)
{
char*subvol, *dst;
- int res, fd, fddst, len;
+ int res, fd, fddst, len, async;
char*newname;
char*dstdir;
subvol = argv[1];
dst = argv[2];
- struct btrfs_ioctl_vol_args args;
+ if (argc 3) {
+ if (strstr(argv[3], async)) {
+ async = 1;
+ } else {
+ fprintf(stderr, ERROR: 'async' expected for third
arg\n);
+ }
+ }
res = test_issubvolume(subvol);
if(res0){
@@ -374,9 +380,22 @@ int do_clone(int argc, char **argv)
printf(Create a snapshot of '%s' in '%s/%s'\n,
subvol, dstdir, newname);
- args.fd = fd;
- strcpy(args.name, newname);
- res = ioctl(fddst, BTRFS_IOC_SNAP_CREATE, args);
+ if (async) {
+ struct btrfs_ioctl_async_vol_args async_args;
+ async_args.fd = fd;
+ async_args.transid = 0;
+ strcpy(async_args.name, newname);
+ res = ioctl(fddst, BTRFS_IOC_SNAP_CREATE_ASYNC, async_args);
+ if (res == 0)
+ printf(transid %llu\n,
+ (unsigned long long)async_args.transid);
+ } else {
+ struct btrfs_ioctl_vol_args args;
+
+ args.fd = fd;
+ strcpy(args.name, newname);
+ res = ioctl(fddst, BTRFS_IOC_SNAP_CREATE, args);
+ }
close(fd);
close(fddst);
diff --git a/btrfs_cmds.h b/btrfs_cmds.h
index 84c489f..bf566ae 100644
--- a/btrfs_cmds.h
+++ b/btrfs_cmds.h
@@ -15,7 +15,7 @@
*/
/* btrfs_cmds.c*/
-int do_clone(int nargs, char **argv);
+int do_create_snap(int nargs, char **argv);
int do_delete_subvolume(int nargs, char **argv);
int do_create_subvol(int nargs, char **argv);
int do_fssync(int nargs, char **argv);
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index e87b5fe..504fe5f 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -5,7 +5,7 @@
.SH NAME
btrfs \- control a btrfs filesystem
.SH SYNOPSIS
-\fBbtrfs\fP \fBsubvolume snapshot\fP\fI source [dest/]name\fP
+\fBbtrfs\fP \fBsubvolume snapshot\fP\fI source [dest/]name [async]\fP
.PP
\fBbtrfs\fP \fBsubvolume delete\fP\fI subvolume\fP
.PP
@@ -74,10 +74,15 @@ command.
.SH COMMANDS
.TP
-\fBsubvolume snapshot\fR\fI source [dest/]name\fR
-Create a writable snapshot of the subvolume \fIsource\fR with the name
-\fIname\fR in the \fIdest\fR directory. If \fIsource\fR is not a
-subvolume, \fBbtrfs\fR returns an error.
+\fBsubvolume snapshot\fR\fI source [dest/]name [async]\fR
+Create a writable snapshot of the subvolume \fIsource\fR with the
+name \fIname\fR in the \fIdest\fR directory. If \fIsource\fR is
+not a subvolume, \fBbtrfs\fR returns an error. If \fI[async]\fR is
+specified, we will not wait for the snapshot creation to commit to
+disk before returning, and a transaction id is printed that can be
+waited on1 using the \fBfilesystem wait-sync\fR command.
+.TP
+
.TP
\fBsubvolume delete\fR\fI subvolume\fR
--
1.7.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
[PATCH v2] btrfs-progs: btrfs: implement 'start-sync' and 'wait-sync' commands
The 'start-sync' command initiates a sync, but does not wait for it to
complete. A transaction is printed that can be fed to 'wait-sync', which
will wait for it to commit.
'wait-sync' can also be used in combination with 'async-snapshot' to wait
for an async snapshot creation to commit.
Updates the man page too.
Signed-off-by: Sage Weil s...@newdream.net
---
btrfs.c|9 +
btrfs_cmds.c | 49 +
btrfs_cmds.h |2 ++
man/btrfs.8.in | 14 ++
4 files changed, 74 insertions(+), 0 deletions(-)
diff --git a/btrfs.c b/btrfs.c
index 46314cf..c871f4a 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -77,6 +77,15 @@ static struct Command commands[] = {
filesystem sync, path\n
Force a sync on the filesystem path.
},
+ { do_start_sync, 1,
+ filesystem start-sync, path\n
+ Start a sync on the filesystem path, and print the
resulting\n
+ transaction id.
+ },
+ { do_wait_sync, 2,
+ filesystem wait-sync, path transid\n
+ Wait for the transaction transid on the filesystem at path
to commit.
+ },
{ do_resize, 2,
filesystem resize, [+/-]newsize[gkm]|max filesystem\n
Resize the file system. If 'max' is passed, the filesystem\n
diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index 8031c58..736437d 100644
--- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -526,6 +526,55 @@ int do_fssync(int argc, char **argv)
return 0;
}
+int do_start_sync(int argc, char **argv)
+{
+ int fd, res;
+ char*path = argv[1];
+ __u64 transid;
+
+ fd = open_file_or_dir(path);
+ if (fd 0) {
+ fprintf(stderr, ERROR: can't access to '%s'\n, path);
+ return 12;
+ }
+
+ printf(StartSync '%s'\n, path);
+ res = ioctl(fd, BTRFS_IOC_START_SYNC, transid);
+ close(fd);
+ if( res 0 ){
+ fprintf(stderr, ERROR: unable to fs-syncing '%s'\n, path);
+ return 16;
+ } else {
+ printf(transid %llu\n, (unsigned long long)transid);
+ }
+
+ return 0;
+}
+
+int do_wait_sync(int argc, char **argv)
+{
+ int fd, res;
+ char*path = argv[1];
+ __u64 transid = atoll(argv[2]);
+
+ fd = open_file_or_dir(path);
+ if (fd 0) {
+ fprintf(stderr, ERROR: can't access to '%s'\n, path);
+ return 12;
+ }
+
+ printf(WaitSync '%s' transid %llu\n, path, (unsigned long
long)transid);
+ res = ioctl(fd, BTRFS_IOC_WAIT_SYNC, transid);
+ close(fd);
+ if( res 0 ){
+ fprintf(stderr, ERROR: unable to wait-sync on '%s' transid
%llu: %s\n, path,
+ (unsigned long long)transid, strerror(errno));
+ return 16;
+ }
+
+ return 0;
+}
+
int do_scan(int argc, char **argv)
{
int i, fd;
diff --git a/btrfs_cmds.h b/btrfs_cmds.h
index 7bde191..84c489f 100644
--- a/btrfs_cmds.h
+++ b/btrfs_cmds.h
@@ -19,6 +19,8 @@ int do_clone(int nargs, char **argv);
int do_delete_subvolume(int nargs, char **argv);
int do_create_subvol(int nargs, char **argv);
int do_fssync(int nargs, char **argv);
+int do_start_sync(int nargs, char **argv);
+int do_wait_sync(int nargs, char **argv);
int do_defrag(int argc, char **argv);
int do_show_filesystem(int nargs, char **argv);
int do_add_volume(int nargs, char **args);
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 26ef982..e87b5fe 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -19,6 +19,10 @@ btrfs \- control a btrfs filesystem
.PP
\fBbtrfs\fP \fBfilesystem sync\fP\fI path \fP
.PP
+\fBbtrfs\fP \fBfilesystem start-sync\fP\fI path \fP
+.PP
+\fBbtrfs\fP \fBfilesystem wait-sync\fP\fI path transid\fP
+.PP
\fBbtrfs\fP \fBfilesystem resize\fP\fI [+/\-]size[gkm]|max filesystem\fP
.PP
\fBbtrfs\fP \fBdevice scan\fP\fI [device [device..]]\fP
@@ -115,6 +119,16 @@ all the block devices.
Force a sync for the filesystem identified by \fIpath\fR.
.TP
+\fBfilesystem start-sync\fR\fI path \fR
+Start a sync operation for the filesystem identified by \fIpath\fR. A
transaction id
+is printed that can be waited on using the \fBfilesystem wait-sync\fR command.
+.TP
+
+\fBfilesystem wait-sync\fR\fI path transid\fR
+Wait for a the transaction \fItransid\fR to commit to disk. If
\fItransid\fR is zero,
+wait for any currently committing transaction to commit.
+.TP
+
.\
.\ Some wording are extracted by the resize2fs man page
.\
--
1.7.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 v2] btrfs-progs: btrfs: implement async option for snapshot command
this would be yet another thing that ioctl#21 could have a flag to wait for. On Mon, Nov 1, 2010 at 11:34 AM, Sage Weil s...@newdream.net wrote: Add an 'async' option to the snapshot creating command, that will let you avoid waiting for a new snapshot to commit to disk. Signed-off-by: Sage Weil s...@newdream.net -- 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 debug messages useless?
I have some partitions on my pc formatted with btrfs and every time I get errors about one of them I can never identify it. I mean, today I got this: [58817.942531] btrfs bad tree block start 4294967297 23652478976 [58817.942899] btrfs bad tree block start 4294967297 23652478976 What am I supposed to get from this? How do I identify the partition that has this problem? All the other fs, while reporting problems, print the partition they're talking about. btrfs doesn't. Why? I didn't want to report this because I thought it was just a matter of time before this would have been solved, but in the end I decided to post here, at least to try to understand if it's just me who's unable to understand how to solve this. -- Giangiacomo -- 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 1/2] Balance progress monitoring (updated)
On 11/01/2010 08:55 PM, Hugo Mills wrote: On Mon, Nov 01, 2010 at 04:06:53PM +0800, liubo wrote: On 10/30/2010 09:39 PM, Hugo Mills wrote: 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. IMO, tracking the information of blocks which are balancing also makes sense. For example, the block information's blocknr. It can help us monitor better. I don't see how that will help. The block group IDs (which is all that we get at this level) are effectively arbitrary 64-bit numbers, and are what appear in the kernel logs. How could that information be used to improve monitoring? 64-bit numbers are also shown in btrfs-debug-tree. With btrfs-debug-tree, it would be helpful to track balanced extent buffers. thanks, liubo I'm not ruling out the idea completely -- I just can't see at the moment how it would be used. Hugo. -- 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 benchmark with 2.6.37-rc1
On 02/11/10 02:12, Morten P.D. Stevens wrote: mkfs.btrfs /dev/sdb mount -t btrfs /dev/sdb /mnt/btrfs It would be interesting to see if the space_cache mount option makes any difference to your numbers. It's commit 0af3d00bad38d3bb9912a60928ad0669f17bdb76. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: Horrible btrfs performance due to fragmentation
[ resend, sorry if anyone sees this twice ] On Sun, Oct 31, 2010 at 09:58:18PM +0200, Felipe Contreras wrote: On Mon, Oct 11, 2010 at 6:46 PM, Calvin Walton calvin.wal...@gmail.com wrote: On Mon, 2010-10-11 at 03:30 +0300, Felipe Contreras wrote: I use btrfs on most of my volumes on my laptop, and I've always felt booting was very slow, but definitely sure is slow, is starting up Google Chrome: encrypted ext4: ~20s btrfs: ~2:11s I have tried different things to find out exactly what is the issue, but haven't quite found it yet. If you've been using this volume for a while, it could just have become badly fragmented. You could try btrfs's fancy online defragmentation abilities to see if that'll give you an improvement: # btrfs filesystem defragment /mountpoint/of/volume Let us know if that helps, of course :) I finally managed to track down this issue. Indeed the fragmentation is horrible, and 'btrfs filesystem defragment' doesn't help: So there are two different issues, and you'll need sysrq-w to see which one you're really hitting. The first is fragmentation, where you'll want to defrag a given file with btrfs filesystem defrag filename The second is that when we first mount a filesystem, we have to spend a long time building up the index of which blocks are free. Josef has fixed this for the 2.6.37-rc1, and Linus' current tree has his changes. You can also pull from the btrfs-unstable master branch and get his changes against 2.6.36. To use the new code, mount -o space_cache. You only need to do this once. The first mount will be slow, but once we've read in the block groups for the first mount, later mounts will be much faster. -chris -- 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
