Re: [PATCH] [RFC] Add btrfs autosnap feature
There's a few things that bother me about this, not least of all the
assumptions it makes about cron,(notably the direct modification of
crontab files, which is considered to be an internal detail if I
understand correctly, and I'm fairly certain is broken as written),
and how it writes to its own config file. Neither has any business in
btrfs-progs in my somewhat irrelevant opinion. :p
It also does not appear to handle mountpoints in its directory walk,
which will cause grief if snapshotting /
There doesn't appear to be any reason for the scratch file to exist at
all (one can build up the hash while reading the directories), and
keeping a scratch file in /etc/ is poor practice in the first place
(that's what /tmp and/or /var/run is for). It's also a lot of io to
stat every file in the subvolume every time you make a snapshot, and
I'm not convinced that the walk is actually correctly implemented:
what stops an autosnap of / from including all of /proc and /sys in
the hash?
Perhaps all that is unnecessary: rather than doing the walk, why not
make use of btrfs subvolume find-new (or rather, the syscalls it
uses)?
Prior to making a new snapshot, grab the (stored) transid of the
previous snapshot, and check if any files have been modified in the
source since that transid: btrfs sub find ${source}
${previous_transid}. If nothing is returned, then you don't have to
bother making the snapshot at all, otherwise after making the
snapshot, grab the transid via btrfs sub find ${new_snapshot} -1,
and store it some place (even a dot file in the root of the snapshot
would work).
This avoids creating and immediately deleting a snapshot every time
nothing has changed, completely avoids the need to stat the entire
subvolume every time, and removes the dependency on the crypto libs.
There's a decent number of other gripes, more related to the actual
code than the design itself, which I'll leave to someone who spends
more time c than I do. A bunch of them are moot in the face the above
anyway.
-- Carey
--
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] [RFC] Add btrfs autosnap feature
On Wed, 29 Feb 2012 10:59:36 +0800 asj anand.j...@oracle.com wrote: This patch adds btrfs autosnap feature. This creates and saves the autosnap config at /etc/autosnap/config. Depending on the configuration, autosnap either schedules the snapshots by updating the crontab or provides an API to trigger the snapshots from the respective applications. The way I see it, this sort of functionality would look more logical in a separate userspace daemon, not in 'btrfs' directly. Such daemon could operate in the background, continuously monitor the FS and create or remove snapshots based on various criteria (and not depend on cron). It could even become filesystem-agnostic, over time adding support for other filesystems with snapshot functionality (ZFS and NILFS2). It could (and should) be a separate project from the btrfs-tools altogether, and a separate OS distribution package. -- With respect, Roman ~~~ Stallman had a printer, with code he could not see. So he began to tinker, and set the software free. signature.asc Description: PGP signature
Re: getdents - ext4 vs btrfs performance
2012/2/29 Jacek Luczak difrost.ker...@gmail.com:
2012/2/29 Chris Mason chris.ma...@oracle.com:
On Wed, Feb 29, 2012 at 03:07:45PM +0100, Jacek Luczak wrote:
[ btrfs faster than ext for find and cp -a ]
2012/2/29 Jacek Luczak difrost.ker...@gmail.com:
I will try to answer the question from the broken email I've sent.
@Lukas, it was always a fresh FS on top of LVM logical volume. I've
been cleaning cache/remounting to sync all data before (re)doing
tests.
The next step is to get cp -a out of the picture, in this case you're
benchmarking both the read speed and the write speed (what are you
copying to btw?).
It's simple cp -a Jenkins{,.bak} so dir to dir copy on same volume.
Using tar cf /dev/zero some_dir is one way to get a consistent picture
of the read speed.
IMO the problem is not - only - in read speed. The directory order hit
here. There's a difference in the sequential tests that place btrfs as
the winner but still this should not have that huge influence on
getdents. I know a bit on the difference between ext4 and btrfs
directory handling and I would not expect that huge difference. On the
production system where the issue has been observed doing some real
work in the background copy takes up to 4h.
For me btrfs looks perfect here, what could be worth checking is the
change of timing in syscall between 39.4 and 3.2.7. Before getdents
was not that high on the list while now it jumps to second position
but without huge impact on the timings.
You can confirm the theory that it is directory order causing problems
by using acp to read the data.
http://oss.oracle.com/~mason/acp/acp-0.6.tar.bz2
Will check this still today and report back.
While I was about to grab acp I've noticed seekwatcher with made my day :)
seekwatcher run of tar cf to eliminate writes (all done on 3.2.7):
1) btrfs: http://dozzie.jarowit.net/~dozzie/luczajac/tar_btrfs.png
2) ext4: http://dozzie.jarowit.net/~dozzie/luczajac/tar_ext4.png
3) both merged: http://dozzie.jarowit.net/~dozzie/luczajac/tar_btrfs_ext4.png
I will send acp results soon.
-Jacek
--
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: [RFC] btrfs auto snapshot
On Thu, Feb 23, 2012 at 04:54:06PM +0700, Fajar A. Nugraha wrote: On Thu, Aug 18, 2011 at 12:38 AM, Matthias G. Eckermann m...@suse.com wrote: are available in the openSUSE buildservice at: http://download.opensuse.org/repositories/home:/mge1512:/snapper/ Hi Matthias, I'm testing your packages on top of RHEL6 + kernel 3.2.7. A small suggestion, you should include /etc/sysconfig/snapper in the package (at least for RHEL6, haven't tested the other ones). Even if it just contains SNAPPER_CONFIGS= Hi Fajar, thanks for reporting that issue, I have fixed it now. We have now created a project in the openSUSE buildservice were we provide snapper packages for various distributions, e.g. RHEL6 and Fedora 16. Please find the downloads at: http://download.opensuse.org/repositories/filesystems:/snapper/ I'll also add a link from the snapper home page: http://en.opensuse.org/Portal:Snapper. I have tested snapper on Fedora 16 and found no problems. Regards, Arvin -- Arvin Schnell, aschn...@suse.de Senior Software Engineer, Research Development SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- 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: getdents - ext4 vs btrfs performance
On Thu, Mar 1, 2012 at 9:35 PM, Jacek Luczak difrost.ker...@gmail.com wrote: While I was about to grab acp I've noticed seekwatcher with made my day :) seekwatcher run of tar cf to eliminate writes (all done on 3.2.7): 1) btrfs: http://dozzie.jarowit.net/~dozzie/luczajac/tar_btrfs.png 2) ext4: http://dozzie.jarowit.net/~dozzie/luczajac/tar_ext4.png 3) both merged: http://dozzie.jarowit.net/~dozzie/luczajac/tar_btrfs_ext4.png I will send acp results soon. Would you please take reiserfs into account? Thanks -hd -- 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: getdents - ext4 vs btrfs performance
2012/3/1 Hillf Danton dhi...@gmail.com: On Thu, Mar 1, 2012 at 9:35 PM, Jacek Luczak difrost.ker...@gmail.com wrote: While I was about to grab acp I've noticed seekwatcher with made my day :) seekwatcher run of tar cf to eliminate writes (all done on 3.2.7): 1) btrfs: http://dozzie.jarowit.net/~dozzie/luczajac/tar_btrfs.png 2) ext4: http://dozzie.jarowit.net/~dozzie/luczajac/tar_ext4.png 3) both merged: http://dozzie.jarowit.net/~dozzie/luczajac/tar_btrfs_ext4.png I will send acp results soon. Would you please take reiserfs into account? As of now not (lack of time) but I'm pretty close to consider XFS in the game. Whenever I will have more time and there won't be a pressure on giving host back to production I will redo same tests for reiserfs. Now I'm focused on the userspace sorting results. -Jacek -- 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: [RFC] btrfs auto snapshot
On Thu, Mar 1, 2012 at 8:48 PM, Arvin Schnell aschn...@suse.de wrote: On Thu, Feb 23, 2012 at 04:54:06PM +0700, Fajar A. Nugraha wrote: On Thu, Aug 18, 2011 at 12:38 AM, Matthias G. Eckermann m...@suse.com wrote: are available in the openSUSE buildservice at: http://download.opensuse.org/repositories/home:/mge1512:/snapper/ Hi Matthias, I'm testing your packages on top of RHEL6 + kernel 3.2.7. A small suggestion, you should include /etc/sysconfig/snapper in the package (at least for RHEL6, haven't tested the other ones). Even if it just contains SNAPPER_CONFIGS= Hi Fajar, thanks for reporting that issue, I have fixed it now. Great! Thanks. We have now created a project in the openSUSE buildservice were we provide snapper packages for various distributions, e.g. RHEL6 and Fedora 16. Please find the downloads at: http://download.opensuse.org/repositories/filesystems:/snapper/ I'll also add a link from the snapper home page: http://en.opensuse.org/Portal:Snapper. I have tested snapper on Fedora 16 and found no problems. When I installed it back then, the first thing that comes to mind was there's no documentation on how to get started. http://en.opensuse.org/openSUSE:Snapper_Tutorial is good, but that' is assuming root is btrfs, and snapper is already configured to snapshot root. For other distros, you need to first create the config manually, e.g. as shown for home in http://en.opensuse.org/openSUSE:Snapper_FAQ Could you update the tutorial, or perhaps create a new quickstart page? I'm kinda reluctant to do it myself since I don't use opensuse, and some of my edits might not reflect the correct way to do it in opensuse. If that's not possible, I'll put up the documentation somewhere else (perhaps the semi-official http://btrfs.ipv5.de/ , or my own wiki). Two other things that I have't find is: - how to add pre and post hooks, so (for example) snapper could create the same pre-post snapshot whenever user runs yum, similar to when a user runs yast in opensuse, - whether a rollback REALLY rolls back everyting (including binary and new/missing files), or is it git-like behavior, or if it only process text files. ... but those two aren't as important as the getting-started documentation. -- Fajar -- 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: getdents - ext4 vs btrfs performance
On Thu, Mar 01, 2012 at 03:03:53PM +0100, Jacek Luczak wrote: 2012/3/1 Hillf Danton dhi...@gmail.com: On Thu, Mar 1, 2012 at 9:35 PM, Jacek Luczak difrost.ker...@gmail.com wrote: While I was about to grab acp I've noticed seekwatcher with made my day :) seekwatcher run of tar cf to eliminate writes (all done on 3.2.7): 1) btrfs: http://dozzie.jarowit.net/~dozzie/luczajac/tar_btrfs.png 2) ext4: http://dozzie.jarowit.net/~dozzie/luczajac/tar_ext4.png 3) both merged: http://dozzie.jarowit.net/~dozzie/luczajac/tar_btrfs_ext4.png Whoa, seekwatcher makes it pretty clear. I will send acp results soon. Would you please take reiserfs into account? As of now not (lack of time) but I'm pretty close to consider XFS in the game. Whenever I will have more time and there won't be a pressure on giving host back to production I will redo same tests for reiserfs. Now I'm focused on the userspace sorting results. reiserfs should have results very similar to ext4. The directory hashing used by reiserfs is going to result in a very random read pattern. XFS will probably beat btrfs in this test. Their directory indexes reflect on disk layout very well. -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
Re: your mail
On Thu, Mar 01, 2012 at 01:58:14PM +0100, David Sterba wrote: On Thu, Mar 01, 2012 at 04:41:02AM -0800, bella tk wrote: I want to use btrfs defrag tool but before that i want to know how much the disk is fragmented. I have tried to use filefrag but it gives me FIBMAP:invalid argument for many times. The only way to trigger FIBMAP on btrfs is to run filefrag with -B option, but it should use FIEMAP by default and it works. With -v option it'll list all extents. We actually disabled bmap to keep the swap code from remembering fixed offsets for btrfs files. The only way to get the mapping is with fiemap. The defrag ioctl won't bother defragging files that are not fragmented. -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
Re: getdents - ext4 vs btrfs performance
On Wed, Feb 29, 2012 at 11:44:31PM -0500, Theodore Tso wrote: You might try sorting the entries returned by readdir by inode number before you stat them.This is a long-standing weakness in ext3/ext4, and it has to do with how we added hashed tree indexes to directories in (a) a backwards compatible way, that (b) was POSIX compliant with respect to adding and removing directory entries concurrently with reading all of the directory entries using readdir. You might try compiling spd_readdir from the e2fsprogs source tree (in the contrib directory): http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=blob;f=contrib/spd_readdir.c;h=f89832cd7146a6f5313162255f057c5a754a4b84;hb=d9a5d37535794842358e1cfe4faa4a89804ed209 … and then using that as a LD_PRELOAD, and see how that changes things. The short version is that we can't easily do this in the kernel since it's a problem that primarily shows up with very big directories, and using non-swappable kernel memory to store all of the directory entries and then sort them so they can be returned in inode number just isn't practical. It is something which can be easily done in userspace, though, and a number of programs (including mutt for its Maildir support) does do, and it helps greatly for workloads where you are calling readdir() followed by something that needs to access the inode (i.e., stat, unlink, etc.) For reading the files, the acp program I sent him tries to do something similar. I had forgotten about spd_readdir though, we should consider hacking that into cp and tar. One interesting note is the page cache used to help here. Picture two tests: A) time tar cf /dev/zero /home and cp -a /home /new_dir_in_new_fs unmount / flush caches B) time tar cf /dev/zero /new_dir_in_new_fs On ext, The time for B used to be much faster than the time for A because the files would get written back to disk in roughly htree order. Based on Jacek's data, that isn't true anymore. -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
Re: getdents - ext4 vs btrfs performance
2012/3/1 Chris Mason chris.ma...@oracle.com: On Thu, Mar 01, 2012 at 03:03:53PM +0100, Jacek Luczak wrote: 2012/3/1 Hillf Danton dhi...@gmail.com: On Thu, Mar 1, 2012 at 9:35 PM, Jacek Luczak difrost.ker...@gmail.com wrote: While I was about to grab acp I've noticed seekwatcher with made my day :) seekwatcher run of tar cf to eliminate writes (all done on 3.2.7): 1) btrfs: http://dozzie.jarowit.net/~dozzie/luczajac/tar_btrfs.png 2) ext4: http://dozzie.jarowit.net/~dozzie/luczajac/tar_ext4.png 3) both merged: http://dozzie.jarowit.net/~dozzie/luczajac/tar_btrfs_ext4.png Whoa, seekwatcher makes it pretty clear. Yep, ext4 is close to my wife's closet. I will send acp results soon. Would you please take reiserfs into account? As of now not (lack of time) but I'm pretty close to consider XFS in the game. Whenever I will have more time and there won't be a pressure on giving host back to production I will redo same tests for reiserfs. Now I'm focused on the userspace sorting results. reiserfs should have results very similar to ext4. The directory hashing used by reiserfs is going to result in a very random read pattern. XFS will probably beat btrfs in this test. Their directory indexes reflect on disk layout very well. True, but not that fast on small files. Except the question I've raised in first mail there's a point in all those action. We are maintaining host that are used for building software: random access, lot of small files and dirs (always a co), heavy parallel IO. We were testing XFS vs ext4 a year ago and XFS was around 10% slower on build times. We did not - yet - done same on btrfs. Now we're looking for replacement for ext4 as we suffer from those issue - but we were not aware of that until stepped into this issue. If you would like me to do some specific tests around ext4 and btrfs, let me know. -Jacek -- 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: getdents - ext4 vs btrfs performance
On Thu, Mar 01, 2012 at 03:43:41PM +0100, Jacek Luczak wrote: 2012/3/1 Chris Mason chris.ma...@oracle.com: XFS will probably beat btrfs in this test. Their directory indexes reflect on disk layout very well. True, but not that fast on small files. Except the question I've raised in first mail there's a point in all those action. We are maintaining host that are used for building software: random access, lot of small files and dirs (always a co), heavy parallel IO. We were testing XFS vs ext4 a year ago and XFS was around 10% slower on build times. We did not - yet - done same on btrfs. Now we're looking for replacement for ext4 as we suffer from those issue - but we were not aware of that until stepped into this issue. If you would like me to do some specific tests around ext4 and btrfs, let me know. I'm always curious to see comparisons in real world workloads. You should definitely consider testing XFS again, the big three filesystems are under pretty constant improvement. For btrfs, please stick to 3.2 kernels and higher. This seeky backup performance is somewhat built into ext4, but as Ted said there are a few workarounds. -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
Re: getdents - ext4 vs btrfs performance
2012/3/1 Chris Mason chris.ma...@oracle.com: On Thu, Mar 01, 2012 at 03:43:41PM +0100, Jacek Luczak wrote: 2012/3/1 Chris Mason chris.ma...@oracle.com: XFS will probably beat btrfs in this test. Their directory indexes reflect on disk layout very well. True, but not that fast on small files. Except the question I've raised in first mail there's a point in all those action. We are maintaining host that are used for building software: random access, lot of small files and dirs (always a co), heavy parallel IO. We were testing XFS vs ext4 a year ago and XFS was around 10% slower on build times. We did not - yet - done same on btrfs. Now we're looking for replacement for ext4 as we suffer from those issue - but we were not aware of that until stepped into this issue. If you would like me to do some specific tests around ext4 and btrfs, let me know. I'm always curious to see comparisons in real world workloads. You should definitely consider testing XFS again, the big three filesystems are under pretty constant improvement. For btrfs, please stick to 3.2 kernels and higher. That's the plan but I'm waiting for more of the briliant work that recently popped up in XFS. For btrfs, the 3.2 introduced changes led me to give here a try. I don't have nice pictures and digits in my hand now but first tests shown close to 40% of timing improvements between 2.6.39.4 and 3.2.7 - keep doing that great work guys (and girls if any)! -Jacek -- 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: getdents - ext4 vs btrfs performance
On Thu, Mar 01, 2012 at 03:43:41PM +0100, Jacek Luczak wrote: Yep, ext4 is close to my wife's closet. Were all of the file systems freshly laid down, or was this an aged ext4 file system? Also you should beware that if you have a workload which is heavy parallel I/O, with lots of random, read/write accesses to small files, a benchmark using tar might not be representative of what you will see in production --- different file systems have different strengths and weaknesses --- and the fact that ext3/ext4's readdir() returns inodes in a non-optimal order for stat(2) or unlink(2) or file copy in the cold cache case may not matter as much as you think in a build server. (i.e., the directories that do need to be searched will probably be serviced out of the dentry cache, etc.) Regards, - Ted -- 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: Set nodatacow per file?
On 02/28/2012 09:51 AM, dima wrote: On 02/28/2012 07:10 AM, Chester wrote: On Mon, Feb 27, 2012 at 7:54 AM, dimadole...@parallels.com wrote: Hello, Since several people asked to post the results, here they are. I tried raw virtio disk with and without -z -C set and also qcow2 virtio disk without -z -C set and did not notice any difference in performance at all - Redhat 6.2 Minimal installs in 10 minutes in each case. The abysmal performance as it was some several months ago (like 10 minutes just for virtual disk formatting) under the same conditions is no more at least on 3.3.0-rc5. Just to make sure, this is a _new_ virtual disk right? I can barely contain my excitement right now. This is amazing progress. Yes, it is a newly created virtual disk. By the way, one thing that slipped out from my message - in case of raw I did pre-allocation of the entire image, but in case of qcow2 I unchecked this box in virt-manager and the disk was growing as the system was installing. Nevertheless I did not notice performance degradation during the install. But still Virtualbox is faster. It installs Redhat 6 Minimal in just about 5 minutes. I observe that yum installations work faster. WindowsXP install under KVM was a hell lasting for about 3 hours and the performance is awful with host HD indicator flashing all the time. There was no change whatsoever whether the image was with +C +z or not. On Virtualbox WinXP install completed in about 25 minutes and the performance is excellent even w/o guest additions applied. I wonder why such a big difference. -- 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
