linux-kernel - [ANNOUNCE] Btrfs v0.9

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20071204155740.0c63bc3e@think.oraclecorp.com>
Date:	Tue, 4 Dec 2007 15:57:40 -0500
From:	Chris Mason <chris.mason@...cle.com> (by way of Chris Mason
	<chris.mason@...cle.com>)
To:	btrfs-devel@....oracle.com, btrfs-announce@....oracle.com
Subject: [ANNOUNCE] Btrfs v0.9

Hello everyone,

I've just tagged and released Btrfs v0.9.  Special thanks to Yan Zheng
and Josef Bacik for their work.

This release includes a number of disk format changes from v0.8 and
also a small change from recent btrfs-unstable HG trees.  So, if you
have existing Btrfs filesystems, you will need to backup, reformat and
restore to try out v0.9.

You can find download links and other details here:

http://oss.oracle.com/projects/btrfs/

Since v0.8:

* Support for btree blocks larger than the page size.  mkfs.btrfs
defaults to 8k blocks, but -l and -n can be used to set the block size
for leaves and nodes.  Powers of 2 are required, example:

mkfs.btrfs -l 32768 -n 32768 /dev/xxxx

* Support for inline (packed into the btree) file data larger than the
page size.  Any file smaller than a btree block will probably be backed
into the btree.

* Xattr support (no ACLs yet) from Josef Bacik.  This works for generic
user xattrs and was tested with beagle among other things.

* Stripe size parameter to mkfs.btrfs (-s size_in_bytes).  Extents will
be aligned to the stripe size for performance.

* Many performance and stability fixes, especially on 32 bit x86
machines.

Unfixed:

ENOSPC handling.  Things are much more predicable now, and
Btrfs will work up until the disk is very close to full.

Concurrency: Everything is still protected by a single mutex, which is
held during IO.  Multi-threaded benchmarks will not perform well.

Database performance: Still very slow in database workloads.

You can get an idea of where Btrfs is headed from the TODO list:

http://oss.oracle.com/projects/btrfs/dist/documentation/todo.html

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/