Hello everyone,
Btrfs v0.14 is now available for download.  Please note the disk format has

changed, and it is not compatible with older versions of Btrfs.
For downloads and documention, please see the Btrfs project page:
http://btrfs.wiki.kernel.org
The oss.oracle.com Btrfs project page will soon start redirecting here.
v0.14 has a few performance fixes and closes some races that could have

allowed corrupted metadata in v0.13.  The major new feature is the ability to

manage multiple devices under a single Btrfs mount.  Raid0, raid1 and raid10

are supported.
Even for single device filesystems, metadata is now duplicated by default. 
Checksums are verified after reads finish and duplicate copies are used if the

checksums don't match.
Multi-device design details can be found here:
http://btrfs.wiki.kernel.org/index.php/Multiple_Device_Support
And sample usage to create and add volumes can be found here:
http://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices
I'm putting up some benchmarks of the new multi-device code as the runs

finish:
http://btrfs.wiki.kernel.org/index.php/Multi-device_Benchmarks
Next up on the Btrfs todo list is finishing off the device removal and IO

error handling code.  After that I'll add more fine grained locking to the

btrees.
Thanks to everyone who has helped contribute to and test this release.
-chris

--

Hello everyone,
I've rolled up some fixes for older kernels and fixed an uninitialized

variables in btrfs-progs that could cause an oops on mount.  I'll wait a few

days to see if other bug reports come in and cut a 0.15 with any other

critical fixes.
Until then, you can find download information on the important fixes so far:
http://btrfs.wiki.kernel.org/index.php/Hot_Fixes
-chris

--

Well it oopses on writes everytime in Ubuntu 8.04 (Hardy). I'd planned

on digging into

it more before spending a bug report, but will send it tonight after

getting to the affected

machine.
With 1 volume on 1 disk, 2 volumes raid1 on 2 disks, or with 2 volumes

raid0 on 2 disks.

something like:

echo omg > /mnt/btrfs/file
Would segfault, exit the current shell, and leave a nice stack trace

in the kernel's ring buffer.
The file gets created as 0 bytes. Unlinking the file works fine via

rm, but any sort of write fails.

Tried and reproduced the bug with stdout redirection, cp, and dd to a

btrfs v0.14 volume.
--

Jeff Schroeder
Don't drink and derive, alcohol and analysis don't mix.

http://www.digitalprognosis.com

--

This is because ubuntu kernels ship with apparmor, you'll need this patch:
If there is a #ifdef IM_A_UBUNTU_KERNEL I can use, I'll do it.  Jeff Mahoney

has a similar patch for SUSE that I've been meaning to merge, but I wanted to

lookup some way to check for ubuntu as well.
-chris
diff -r e7da2489b19b file.c

--- a/file.c	Wed Apr 30 13:59:35 2008 -0400

+++ b/file.c	Thu May 01 12:25:11 2008 -0400

@@ -852,7 +852,7 @@ static ssize_t btrfs_file_write(struct f

 		goto out_nolock;

 	if (count == 0)

 		goto out_nolock;

-	err = remove_suid(fdentry(file));

+	err = remove_suid(&file->f_path);

 	if (err)

 		goto out_nolock;

 	file_update_time(file);

--

adding the ubuntu kernel team. BenC or TimG, do you have any

suggestions for Chris?
--

Jeff Schroeder
Don't drink and derive, alcohol and analysis don't mix.

http://www.digitalprognosis.com

--

Couldn't you #ifdef based on CONFIG_SECURITY_APPARMOR ? This ought to

work for Hardy. However the next development kernel (Intrepid) does not

have the APPARMOR patches, so just knowing that its an UBUNTU kernel is

not specific enough.
rtg

--

Tim Gardner tim.gardner@ubuntu.com

--

On Thursday 01 May 2008, Tim Gardner wrote:
I've been assuming the apparmor patches change remove_suid even when they are

not enabled in the config.
-chris

--

Lets get Kees involved. He developed the patch set for Hardy. I would

hope that if CONFIG_SECURITY_APPARMOR=n then the source would default to

its normal state.
rtg

--

Tim Gardner tim.gardner@ubuntu.com

--

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
remove_suid() isn't the only change AppArmor makes to the VFS interface.

It's pretty invasive and requires that dentries are passed with a

companion vfsmount in most cases. Putting #ifdefs around all that code

would make the problem worse, not better.
- -Jeff
- --

Jeff Mahoney

SUSE Labs

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2.0.4-svn0 (GNU/Linux)

Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFIGiOrLPWxlyuTD7IRAh3jAKCFCrBa30G5WDwmJHI+Yb4fNAfu2QCfTUmq

Q6Sf0MVug2X0ywRcSrGi4eY=

=QwF9

-----END PGP SIGNATURE-----

--

An alternative approach, and IMHO better suited, is to:
	make -C ${kdir} all I_HAZ_AN_APPARMOR=1
with this Makefile
	ifneq (${I_HAZ_AN_APPARMOR},)

	EXTRA_CFLAGS += -DHAZ_APPARMOR

	endif
This works very well for kmp-rpms, which are tied to a specific

distro, sometimes kernel, anyway.

--

This is better than the current situation (oops without any clues), but I'd

prefer that people not have to know what apparmor is or if they have it.

(This isn't a knock on apparmor, I'd just rather take care of it

automagically).
-chris

--

Chris,
Make is not my forte, but here is a working test to see if apparmor

exists in Ubuntu 8.04.

Maybe have make apply a patch to the btrfs source if this test

succeeds? Does this work in SUSE?
http://www.digitalprognosis.com/opensource/patches/btrfs/lame_apparmor_t...
The symlink from /lib/modules/`uname -r`/build ->

/path/to/kernel/headers/ doesn't exist on CentOS 5.

Even though it is a hack, is this or something like it usable? Or is

this the completely wrong direction?
--

Jeff Schroeder
Don't drink and derive, alcohol and analysis don't mix.

http://www.digitalprognosis.com

--

On Friday 02 May 2008, Jeff Schroeder wrote:
Thanks, but this uses CONFIG_SECURITY_APPARMOR which isn't enough to tell if

the kernel has the patch.  Lets go back to Jeff's suse patch:
/*

 * Even if AppArmor isn't enabled, it still has different prototypes.

 * Add more distro/version pairs here to declare which has AppArmor applied.

 */

#if defined(CONFIG_SUSE_KERNEL)

# if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,22)

# define REMOVE_SUID_PATH 1

# endif

#endif
Could someone from Ubuntu please suggest a replacement for CONFIG_SUSE_KERNEL

and KERNEL_VERSION(2,6,22) that would correspond with ubuntu kernels shipped

with apparmor?  We don't need some define from the apparmor patch, just a

global flag that says it comes from ubuntu is enough.
-chris

--

To the best of my knowledge, the AppArmor patches are arch and flavour

independent. If CONFIG_SECURITY_APPARMOR exists, then the AA code is

compiled. This is certainly the case for Hardy. Neither Kees or myself

are aware of any reason why it won't also hold true for Intrepid.
rtg

--

Tim Gardner timg@tpi.com www.tpi.com

OR 503-601-0234 x102 MT 406-443-5357

--

I ended up using the CONFIG_SECURITY_APPARMOR test because the other test

suggested here sounded like something that might eventually not be very

ubuntu specific (instead of the nice a plain CONFIG_SUSE_KERNEL).
Thanks to everyone for the hints, if someone could please test:
http://btrfs.wiki.kernel.org/index.php/Hot_Fixes
I'd be grateful.
-chris

--

Do we really need to support kernels compiled with the apparmour patch

applied but not enabled?  That would be a custom kernel build, and I get

the impression that people Just Don't Do That -- if they want a newer

kernel, they fetch one from kernel.org.  Maybe I'm wrong though.
--

Intel are signing my paycheques ... these opinions are still mine

"Bill, look, we understand that you're interested in selling us this

operating system, but compare it to ours.  We can't possibly take such

a retrograde step."

--

I think so too. Corollary: if there is a distro that has apparmor

patched into its kernel, then there is [hopefully] a suitable rpm

nearby.

--

Yeah, if there's no better test I'll just use the one for the apparmor config

(and stop spamming l-k with this btrfs specific stuff).
-chris
--

Woah, you rely on autoconf.h. Uh no thanks, let the build system handle it.
# -*- Makefile -*-
btrfs-objs := ...

obj-m += btrfs.o and-so-on.o
ifneq (${CONFIG_SECURITY_APPARMOR},)

EXTRA_CFLAGS += -DI_HAZ_AN_APPARMOR

endif
all:

	${MAKE} -C ${kdir} M=$PWD all;
Best of all, you can override that from the command line too...
	make CONFIG_SECURITY_APPARMOR=y
(and if you don't, it takes its value from the appropriate .config,

all without you having to care about autoconf.h)

--

^
If it oopses, then you probably also get a compile-time warning on

that remove_suid line. And in that case, you can catch it with at least

a compile-time typecheck so as to not make the user head straight into

an oops, is not it?

--

I guess iff people have a clue just what btrfs is and what it is good for

and why one would need it, I guess they also know of Apparmor.

If not, well, I hope you mentioned it in the INSTALL file!
Well you could go down the conftest.sh route, but I dislike that

approach because such a Makefile system tries to be smarter than me;

and that often breaks because developers made a mess out of the

remaining Makefile and before long, it broke on odd, but

"standards-conforming", O= builds. (Fun stories with nvidia.)

--

Hi,
I can't claim to have developed the patches, only helping coordinate

their merging into Ubuntu.  John Johansen is the real person we should

check with -- he did all the heavy lifting -- now added to discussion.

(Hi John!)
-Kees
--

Kees Cook

Ubuntu Security Team

--

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Yeah, unless Ubuntu is doing some magic with the function arguments

(which sounds like the fix is worse than the problem), this is true.
- -Jeff
- --

Jeff Mahoney

SUSE Labs

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2.0.4-svn0 (GNU/Linux)

Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFIGhmULPWxlyuTD7IRAgJcAJ4zYYcgQ2V0eT6Fv6LstlwpnK9bUwCgpdBD

XHUzfiFBd+HQLt5Tw5vHH0A=

=KWIZ

-----END PGP SIGNATURE-----

--