Hello everyone, Btrfs v0.10 is now available for download from: http://oss.oracle.com/projects/btrfs/ Btrfs is still in an early alpha state, and the disk format is not finalized. v0.10 introduces a new disk format, and is not compatible with v0.9. The core of this release is explicit back references for all metadata blocks, data extents, and directory items. These are a crucial building block for future features such as online fsck and migration between devices. The back references are verified during deletes, and the extent back references are checked by the existing offline fsck tool. For all of the details of how the back references are maintained, please see the design document: http://oss.oracle.com/projects/btrfs/dist/documentation/btrfs-design.html Other new features (described in detail below): * Online resizing (including shrinking) * In place conversion from Ext3 to Btrfs * data=ordered support * Mount options to disable data COW and checksumming * Barrier support for sata and IDE drives [ Resizing ] In order to demonstrate and test the back references, I've added an online resizer, which can both grow and shrink the filesystem: mount -t btrfs /dev/xxx /mnt # add 2GB to the FS btrfsctl -r +2g /mnt # shrink the FS by 4GB btrfsctl -r -4g /mnt # Explicitly set the FS size btrfsctl -r 20g /mnt btrfsctl -r max /mnt [ Conversion from Ext3 ] This is an offline, in place, conversion program written by Yan Zheng. It has been through basic testing, but should not be trusted with critical data. To build the conversion program, run 'make convert' in the btrfs-progs tree. It depends on libe2fs and acl development libraries. The conversion program uses the copy on write nature of Btrfs to preserve the original Ext3 FS, sharing the data blocks between Btrfs and Ext3 metadata. Btrfs metadata is created inside the free space of the Ext3 filesystem, and it is possible to either make the conversion permanent (reclaiming the space used by Ext3) or roll back the conversion to the original Ext3 filesystem. More details and example usage of the conversion program can be found here: http://oss.oracle.com/projects/btrfs/dist/documentation/btrfs-converter.html Thanks to Yan Zheng for all of his work on the converter. [ New mount options ] mount -o nodatacsum disables checksumming on data extents mount -o nodatacow disables copy on write of data extents, unless a given extent is referenced by more than one snapshot. This is targeted at database workloads, where copy on write is not optimal for performance. However the explicit back references allow the nodatacow code to make sure copy on write is done when multiple snapshots reference the same file, maintaining snapshot consistency. mount -o alloc_start=num forces allocation hints to start at least num bytes into the disk. This was introduced to test the resizer. Example usage: mount -o alloc_start=16g /dev/xxxx /mnt (do something to the FS) btrfsctl -r 12g /mnt The btrfsctl command will resize the FS down to 12GB in size. Because the FS was mounted with -o alloc_start=16g, any allocations done after mounting will need to be relocated by the resizer. It is safe to specify a number past the end of the FS, if the alloc_start is too large, it is ignored. mount -o nobarrier disables cache flushes during commit.
Bron Gondwana
2008-Jan-28 03:55 UTC
[Btrfs-devel] Re: [Btrfs-announce] [ANNOUNCE] Btrfs v0.10 available
(still away at the choir festival for another week... but I got online and downloaded a bunch of emails) On Fri, Jan 18, 2008 at 08:46:23AM -0500, Chris mason wrote:> On Thursday 17 January 2008, Bron Gondwana wrote: > > On Tue, Jan 15, 2008 at 10:53:29AM -0500, Chris Mason wrote: > > > Btrfs is still in an early alpha state, and the disk format is not > > > finalized. v0.10 introduces a new disk format, and is not compatible with > > > v0.9. > > > > > > The core of this release is explicit back references for all metadata > > > blocks, data extents, and directory items. These are a crucial building > > > block for future features such as online fsck and migration between > > > devices. The back references are verified during deletes, and the extent > > > back references are checked by the existing offline fsck tool. > > > > Just as a random datapoint, Maildir access (read only) via mutt feels > > much more sluggish than on 0.5, which is the last release of btrfs I > > played with. The Maildirs have just been created by using rsync to > > copy them from my usual reiserfs partition. It's still massively > > slower than reiserfs for the Maildir access pattern that I have. > > With atimes on or off? What is the maildir access pattern? The backrefs make > it possible to do a bunch of interesting readdir optimizations.That's a point, mounted btrfs as "default" but reiserfs is noatime,nodiratime. I'll go add a noatime to the btrfs mount options and try that. Access pattern is whatever mutt is doing - presumably getting a directory listing and then reading the start of each file it hasn't got in its cache yet.> You'll also bang into the locking if you have a number of processes doing > cold-cache reads at the same time.Generally not - it's either just the single mutt process or a mutt process and a (multi-threaded) python offlineimap process - but I always run them by hand, and only when I'm online (obviously). Bron.
On Sat, Jan 26, 2008 at 11:18:31PM +1100, Bron Gondwana wrote:> On Fri, Jan 18, 2008 at 08:46:23AM -0500, Chris mason wrote: > > On Thursday 17 January 2008, Bron Gondwana wrote: > > > Just as a random datapoint, Maildir access (read only) via mutt feels > > > much more sluggish than on 0.5, which is the last release of btrfs I > > > played with. The Maildirs have just been created by using rsync to > > > copy them from my usual reiserfs partition. It's still massively > > > slower than reiserfs for the Maildir access pattern that I have. > > > > With atimes on or off? What is the maildir access pattern? The backrefs make > > it possible to do a bunch of interesting readdir optimizations. > > That's a point, mounted btrfs as "default" but reiserfs is > noatime,nodiratime. I'll go add a noatime to the btrfs mount > options and try that.It didn't help noticably, and neither did 0.11, however 0.12 is looking good so far (I left my laptop at home today, so I'm accessing it over an ssh link which makes getting a real feel for behaviour harder - but it is significantly quicker.) As a rough guide I'd say mailboxes with a few new messages load about 5-10 times as fast - which is really quite a big change! Bron ( happy )