Gentoo Forums

Posted: **Fri Jun 15, 2007 9:03 am**

Hi,

Did anybody of you try Btrfs yet (it's still in early alpha stages, I know)? It's a filesystem that is being developed by Chris Mason, which has, or will have, about the same properties as ZFS (snapshots, checksums on data and metadata, fast filesystem checking, etc.)
I'm currently compiling kernel 2.6.21 (thats what it needs, 2.6.20 won't work), and will report back when I have it working.

See also:
http://oss.oracle.com/~mason/btrfs/
http://kerneltrap.org/node/8376

Posted: **Fri Jun 15, 2007 9:40 am**

I have it working. Didn't have any OOPS yet

I put my portage tree on it, and it seems to work correctly. Performance isn't too bad either.
Let's hope this will develop into something like ZFS!

Posted: **Fri Jun 15, 2007 11:12 am**

Keep us informed

Posted: **Fri Jun 15, 2007 11:33 am**

BlackEdder wrote:Keep us informed

+1

Posted: **Fri Jun 15, 2007 11:58 am**

Ok, it's not as great yet as I thought. After an emerge --sync there appears to be some corruption (portage gives CacheCorruption errors.) Other than that, it works great, especially snapshotting is awesome to have at filesystem level

Posted: **Fri Jun 15, 2007 9:01 pm**

Good thing data corruption is only a minor issue in filesystems.

J/k, keep up the good work

Posted: **Sun Jun 17, 2007 8:49 am**

Seems it was an mmap bug. The author is fixing it.

Posted: **Tue Jun 19, 2007 9:36 pm**

AforAlexander wrote:data corruption is only a minor issue in filesystems.

Hilarious

This definitely needs to become a famous signature quote

Posted: **Wed Jun 20, 2007 2:00 am**

frenkel
you could try ZFS on FUSE

Posted: **Wed Jun 20, 2007 7:10 am**

I don't like FUSE, and the ZFS implementation is very limited and slow. Btrfs is much better and faster, plus it's developed by Oracle.

Posted: **Thu Jun 21, 2007 9:40 am**

how efficient in terms of harddisk space usage is it?

they wrote, that it's efficient with small-files packing, so results should be pretty similar to reiserfs (v3.6) and/or reiser4

could you post some details:

du -hs /usr/portage

df -h /usr/portage

thanks in advance

Posted: **Thu Jun 21, 2007 9:46 am**

There is still some issue with corruption, so I can't look at that right now, we are first trying to find out where the corruption comes from.

Posted: **Fri Jun 22, 2007 10:12 am**

didn't Chris Mason write the log for reiserfs ?

good boy

I'll love to test that filesystem after it has advanced a little in development

Posted: **Sat Jun 23, 2007 6:36 pm**

The corruptions bug was fixed, apparently it only showed up on 32bit systems, thats why the dev didn't find it at first.
Give it a try!

Posted: **Mon Jun 25, 2007 7:59 pm**

is this fs actually writable ?

rsync -azurP --delete /usr/portage/ /test/
building file list ...
160400 files to consider
rsync: delete_file: rmdir "/test/default" failed: Operation not permitted (1)
./
.ebuild.x
1045133 100% 11.10MB/s 0:00:00 (xfer#1, to-check=160398/160400)
rsync: mkstemp "/test/..ebuild.x.fIoAHy" failed: Permission denied (13)
rsync: symlink "/test/distfiles" -> "/data/distfiles/" failed: Operation not permitted (1)
header.txt
121 100% 1.33kB/s 0:00:00 (xfer#2, to-check=160396/160400)
skel.ChangeLog
3666 100% 37.69kB/s 0:00:00 (xfer#3, to-check=160395/160400)
skel.ebuild
7176 100% 70.79kB/s 0:00:00 (xfer#4, to-check=160394/160400)
skel.metadata.xml
881 100% 8.69kB/s 0:00:00 (xfer#5, to-check=160393/160400)
.cache/
rsync: recv_generator: mkdir "/test/.cache" failed: Operation not permitted (1)
*** Skipping everything below this failed directory ***
app-accessibility/
rsync: recv_generator: mkdir "/test/app-accessibility" failed: Operation not permitted (1)
*** Skipping everything below this failed directory ***
app-admin/
rsync: recv_generator: mkdir "/test/app-admin" failed: Operation not permitted (1)
*** Skipping everything below this failed directory ***

/dev/sdd6 on /test type btrfs (rw)

using v0.4

thanks in advance

- this was just a small peak, I unforunately don't have the time to test it any deeper (but would like to, due to limited time)

keep on the good work

this fs has potential

Posted: **Tue Jun 26, 2007 8:12 am**

kernelOfTruth wrote:is this fs actually writable ?

rsync -azurP --delete /usr/portage/ /test/
building file list ...
160400 files to consider
rsync: delete_file: rmdir "/test/default" failed: Operation not permitted (1)
./
.ebuild.x
1045133 100% 11.10MB/s 0:00:00 (xfer#1, to-check=160398/160400)
rsync: mkstemp "/test/..ebuild.x.fIoAHy" failed: Permission denied (13)
rsync: symlink "/test/distfiles" -> "/data/distfiles/" failed: Operation not permitted (1)
header.txt
121 100% 1.33kB/s 0:00:00 (xfer#2, to-check=160396/160400)
skel.ChangeLog
3666 100% 37.69kB/s 0:00:00 (xfer#3, to-check=160395/160400)
skel.ebuild
7176 100% 70.79kB/s 0:00:00 (xfer#4, to-check=160394/160400)
skel.metadata.xml
881 100% 8.69kB/s 0:00:00 (xfer#5, to-check=160393/160400)
.cache/
rsync: recv_generator: mkdir "/test/.cache" failed: Operation not permitted (1)
*** Skipping everything below this failed directory ***
app-accessibility/
rsync: recv_generator: mkdir "/test/app-accessibility" failed: Operation not permitted (1)
*** Skipping everything below this failed directory ***
app-admin/
rsync: recv_generator: mkdir "/test/app-admin" failed: Operation not permitted (1)
*** Skipping everything below this failed directory ***

/dev/sdd6 on /test type btrfs (rw)
using v0.4

thanks in advance

- this was just a small peak, I unforunately don't have the time to test it any deeper (but would like to, due to limited time)

keep on the good work

this fs has potential

Direct in the root, you can create "sub file systems". By default there is only 1, named "default". Snapshots are also saved in this place. You should create a subfilesystem like this: btrfsctl -s portage /test. Then you can sync to /test/portage/
I don't know if the developer want's to keep it like this, I thought he was considering make a .snaps dir with the snapshots, and make the root normally writable, so you can use it as your / also.

Frank

Posted: **Tue Jun 26, 2007 8:32 am**

Thanks, Frank,

now it finally worked

it seems to be pretty fast & efficient with space usage too:

/dev/sdd6 btrfs 4,7G 281M 4,4G 6% /test
/dev/sdc8 reiser4 152G 42G 111G 28% /data
/dev/sdc7 reiser4 4,5G 144M 4,3G 4% /usr/portage

that reiser4 partition on /usr/portage uses lzo1 compression, so the result should be just fine

this is the result with a normal formatted reiser4-partition:

/dev/sdd6 reiser4 4,5G 215M 4,3G 5% /test

ok, some other results:

reiserfs with -o noatime,nodiratime,data=writeback,commit=120

sent 83604570 bytes received 3137684 bytes 2040994.21 bytes/sec
total size is 173726829 speedup is 2.00

real 0m43.363s
user 0m21.172s
sys 0m23.407s
lexa-x86 bin # time sync

real 0m4.077s
user 0m0.001s
sys 0m0.356s

reiser4 with -o noatime,nodiratime

sent 83604570 bytes received 3137684 bytes 2668992.43 bytes/sec
total size is 173726829 speedup is 2.00

real 0m32.423s
user 0m21.371s
sys 0m21.048s
lexa-x86 bin # time sync

real 0m5.703s
user 0m0.000s
sys 0m0.090s

btrfs with -o noatime,nodiratime

83604570 bytes received 3137684 bytes 2844008.33 bytes/sec
total size is 173726829 speedup is 2.00

real 0m30.625s
user 0m20.915s
sys 0m19.073s
lexa-x86 bin # time sync

real 0m1.883s
user 0m0.000s
sys 0m0.236s

pretty impressive for it's state, I'm pretty sure it will get faster

- so it's already now faster than a default reiser4 partition (all data was in cache, so a pretty subjective test

)

given it's integrity checks & features it could develop into a strong competition of zfs ...

Posted: **Tue Jun 26, 2007 8:36 am**

And don't forget the snapshots! They work already, and it takes less than a second to create one

(Only problem there still is now, is that you can't remove subfilesystems and snapshots....

, you can, however delete everything from a snapshot or subfilesystem)

Posted: **Tue Jun 26, 2007 9:19 am**

just noticed that data corruption somehow still exist:

[ 1385.605496] btrfs: sdd6 checksum verify failed on 4
[ 1385.605682] btrfs: sdd6 checksum verify failed on 12
[ 1385.605874] btrfs: sdd6 checksum verify failed on 11
[ 1395.229653] btrfs: sdd6 checksum verify failed on 10

one "wish":
it should be at least as efficient with space usage like jfs & reiserfs (space usage: jfs ~ reiserfsv3.6)

then this will be my filesystem of choice (since reiser4 unfortunately still has some little glitches, which should hopefully be fixed soon)

will test that out later ...

Posted: **Tue Jun 26, 2007 9:24 am**

kernelOfTruth wrote:just noticed that data corruption somehow still exist:

[ 1385.605496] btrfs: sdd6 checksum verify failed on 4
[ 1385.605682] btrfs: sdd6 checksum verify failed on 12
[ 1385.605874] btrfs: sdd6 checksum verify failed on 11
[ 1395.229653] btrfs: sdd6 checksum verify failed on 10
one "wish":
it should be at least as efficient with space usage like jfs & reiserfs (space usage: jfs ~ reiserfsv3.6)

then this will be my filesystem of choice (since reiser4 unfortunately still has some little glitches, which should hopefully be fixed soon)

will test that out later ...

Those are checksums of some metadata (for the root), which aren't checksummed yet. Somebody created a patch for this, so that mkfs does this checksums. It will be in the next release I think.

Posted: **Fri Jun 29, 2007 8:31 am**

is filesystem compression an option for this fs ?

(similar to reiser4) or will this be handled via kernel ?

Posted: **Fri Jun 29, 2007 8:55 am**

kernelOfTruth wrote:is filesystem compression an option for this fs ?

(similar to reiser4) or will this be handled via kernel ?

This isn't an option (yet?). What do you mean with "will this be handled via kernel?"?

Posted: **Fri Jun 29, 2007 10:03 am**

I refer to dm-crypt & cryptsetup-luks, device-mapper

Posted: **Fri Jun 29, 2007 10:05 am**

kernelOfTruth wrote:I refer to dm-crypt & cryptsetup-luks, device-mapper

That's encryption, not compression...

Posted: **Fri Jun 29, 2007 10:07 am**

frenkel wrote:
kernelOfTruth wrote:I refer to dm-crypt & cryptsetup-luks, device-mapper
That's encryption, not compression...

oops, got me

(sleeping not much is no good)

I actually meant:

* Ext2 Compression Extension
* compFUSEd: transparent compression filesystem for Linux

so this isn't really handled by kernel, rather by userspace utils & fuse

just found this:

http://blog.pebcak.de/archives/492-ZFS- ... cache.html

so btrfs definitely needs compression for good competition against zfs

(ok, ok just some theoretical stuff, but nevetheless impressive)

Gentoo Forums

New filesystem: Btrfs!

New filesystem: Btrfs!