In fact I tried to use it as the main file system on a fresh install of Wheezy: I aborted the installation when I saw it was still at 30% and crawling after a couple hours. A second installation with ext4 was flawlessly completed in less than 30 minutes.

My netbook only sports SSD, no rotating disks. Could that be the cause of the issue?

This includes a fairly large change from Josef around data writeback completion. Before, the writeback wasn't completed until the metadata insertions for the extent were done, and this made for fairly large latency spikes on the last page of each ordered extent.

We already had a separate mechanism for tracking pending metadata insertions, so Josef just needed to tweak things a little to end writeback earlier on the page. Overall it makes us much friendly to memory reclaim and lowers latencies quite a lot for synchronous IO.

I said no because I'm happy with ext3 or XFS. My server runs XFS and that's been very stable, never had an issue ever. Ext3 on my other boxes, it needs routine fscking on boot and it does fragment quite a bit between fscks (30 boot interval). My next systems will probably be ext4 because it's a natural progression from ext3 and I think it will be the Debian default by then.

Btrfs is supposed to be really good but I'll wait a bit before I take the plunge.

I use XFS for almost every machine and it works really good...nearly perfect.
I wanna let btrfs mature a bit and then i would switch because of de Check-summing and the transparent compression...but check-summing is the most important thing for me (data erosion on slow high-density hard-drives)

My main reason for Debian not being my primary O/S is ZFS. Once btrfs equals the level of quality i get with ZFS, I'll leave FreeBSD and head back to Debian as I do tend to like the userland a bit better in linux.

Like most, I do not use BTRFS yet (mainly due lack of disc check/repair options); but I have tried it a few times with various media. It seems to be quite unstable still (as of kernel 3.5), but it has great potential as an alternate filesystem in the near future. Currently BTRFS is quite slow on disc drives, but with the right settings, it seems to really excel at running on solid state drives and especially on SD cards.

With (forced) compression enabled, solid state mode enabled, and a few small changes to the default settings, BTRFS seems to out perform the others on an SD card when testing it on my Vostro 3500 laptop. After my hard drive failed earlier this year, I was able to use this on a 16GB SD card for several months (with heavy usage) before the card finally wore out. It would be interesting to see someone benchmark this using SD cards as the media instead and see how this effects the outcome.

Using it currently on Fedora 17 x86_64, Seems to be working fine for the most part, but takes a long time to log in after reboot. I assume this is a cacheing issue, since I see high wait states during the login.

I'm using btrfs on multiple machines two years now. Never had any problems. One note though: It really gets slower as you create more snapshots. But I don't really care, because for my use, a machine with enough RAM has everything cached, so I can only take notice on this slowness when I reboot, which is really rare.