You are not logged in.
Pages: 1
Hi,
As of kernel 2.6.29 there's going to be support for btrfs. From what I hear, its already usable, albeit at one's own risk
. Anybody experimenting here (the forum search turned out essentially nothing)?
Offline
http://bbs.archlinux.org/viewtopic.php? … 99#p485799 and then page 3.
Offline
Is it just me or does that thread only have 2 pages currently?
Offline
I see 3 pages.
Thinkpad T61p - 15.4' WSXGA TFT - 2.5Ghz Intel Core2 Duo T9300 - 2X2GB Kingston RAM - 160GB 7200RPM - NVIDIA Quadro FX 570m - Intel 4965AGN
Offline
You should know that BTRFS is still in early stage of development . The disk format is not finalized yet and new features are still getting implemented . Every time the disk format changes you will have to reformat .
English is not my native language .
Offline
Offline
AFAIK Btrfs disk format will be kept pretty stable now its in the mainline kernel, and it was hoped to be released Q408, which may still happen but i doubt it.
Offline
btrfs will be, by all accounts, in 2.6.29 (unless obviously if something goes very wrong).
From what I understand, the format is either done or close to it, and most features are done, but it's still very slow as it has not yet been optimized. This is all hearsay, though.
Offline
This is what main developer Chris Mason wrote when Btrfs 0.17 was released a month ago:
"In general, the disk format isn't going to change unless we find a
critical bug with the old format. Every attempt will be made to
maintain backwards compatibility."
http://www.mail-archive.com/linux-btrfs … 01645.html
AFAIK, the disk format haven't changed since then.
Offline
Wanted to compare unpacking time on ext4 and btrfs, here's the btrfs one, khkh:
[18:32:23][root@kingdom]# time tar xf openoffice-base-3.0.1-1-i686.pkg.tar.gz
zsh: segmentation fault tar xf openoffice-base-3.0.1-1-i686.pkg.tar.gz
Real: 9.12s User: 0.07s System: 1.92s Percent: 21% Cmd: tar xf openoffice-base-3.0.1-1-i686.pkg.tar.gz(it seems the partition got full, but well, it didn't handle it gracefully)
Last edited by lucke (2009-02-13 17:37:15)
Offline
Okay, very rigid tests (with standard mkfs/mount options and dropping caches in between tests):
btrfs without compression:
Real: 4.74s User: 1.30s System: 2.58s Percent: 82% Cmd: tar xf kernel26-2.6.28.5-1-i686.pkg.tar.gz
/dev/sda7 510M 224M 287M 44% /home/lucke/h
btrfs with compression:
Real: 4.53s User: 1.30s System: 2.40s Percent: 81% Cmd: tar xf kernel26-2.6.28.5-1-i686.pkg.tar.gz
/dev/sda7 510M 59M 452M 12% /home/lucke/h
ext4:
Real: 3.21s User: 1.52s System: 0.75s Percent: 70% Cmd: tar xf kernel26-2.6.28.5-1-i686.pkg.tar.gz
/dev/sda7 494M 129M 340M 28% /home/lucke/hedit: I got 24% space occupied on subsequent runs of btrfs without compression. Human error?
edit2: And it's 14% for the second one. Delayed allocation in this case, I presume.
Last edited by lucke (2009-02-13 18:14:43)
Offline
Pages: 1