Comment 26 for bug 894456

That's only partly what I wanted to say. Here's a comparison of btrfsck and e2fsck (different devices as I put btrfs on an SD card for this):

Case 1: FS mounted RW
e2fsck: sees that the FS is mounted and errors out as in your post.
$ sudo btrfsck /dev/mmcblk0p1
/dev/mmcblk0p1 is currently mounted. Aborting.

Both abort as they should. OK

Case 2: FS unmounted
$ sudo e2fsck /dev/sdb1
e2fsck 1.42 (29-Nov-2011)
/dev/sdb1: clean, 249/33200 files, 35453/132528 blocks
$ sudo btrfsck /dev/mmcblk0p1
checking extents
checking fs roots
checking root refs
found 28672 bytes used err is 0
total csum bytes: 0
total tree bytes: 28672
total fs tree bytes: 8192
btree space waste bytes: 24411
file data blocks allocated: 0
 referenced 0
Btrfs Btrfs v0.19

Both do a simple check of the FS and return 0. OK

Case 3: FS mounted RO (this is the case on system bootup which we care about. mountall will call fsck -n <device> here)
$ sudo e2fsck -n /dev/sdb1
e2fsck 1.42 (29-Nov-2011)
Warning! /dev/sdb1 is mounted.
/dev/sdb1: clean, 249/33200 files, 35453/132528 blocks
$ sudo btrfsck -n /dev/mmcblk0p1
/dev/mmcblk0p1 is currently mounted. Aborting.
-> exit status 240
-> mountall sees that fsck returned with non-zero exit status and you end up on the rescue prompt.
(that's the patched btrfsck from the package, otherwise it'll fail because it doesn't recognise -n)

So, that leaves us with an fsck.btrfs that's unusable for mountall purposes. I choose to symlink /bin/true, as that's a simple way to not re-introduce bug 660649.
Solution 2 as I said would be a script that at least tells you that fsck.btrfs does nothing, and how you're supposed to use btrfsck.
Solution 3 would be to actually make -n do something useful, which would have to be done by the btrfsck developer. OR we adjust our btrfsck patch so it makes -n simply exit without doing anything.

Opinions?