Btrfs File-System For Old Computers?

[sbergman27]

Data loss.

Barriers are being phased out. They turned out not to be worth the cost. Individual filesystems can accomplish the same thing with less cost simply by making the right calls at the right times.

[liam]

It depends on what you want. For some people running 'noatime' is unacceptable because the atime is data that is valuable for their specific purpose.

Btrfs is going to be a bit slower then Ext4 generally. Ext4 is a very fast FS, despite what the naysayers think. Especially when it comes to pure database purposes... the database uses directio which is something ext4 can be fantastic at...

That being said due to the features and extra levels of protection btrfs can offer then it's probably worth it to use it in the future. When btrfsck comes out then I will start taking btrfs more seriously.

You're spot on about ext4 being a very performant fs (at least, potentially). That is the reason, I would hazard, that Google hired T'so. A lot of his work has been targeted at making ext4 scale to extremely large file systems, and it's paying off for everyone.
As for data protection, although ext4 doesn't protect the data as strongly as zfs/btrfs (again, potentially), it does provide fairly strong protection to the journal which, while should make it harder for the system to become corrupted (if performance isn't important I guess you could make the journal writethrough and that should provide additional data guarantees). Additionally, it has an online defragger, but as it is experimental, I've been hesitant to try it, but it should help keep to maintain performance over machines with very long uptimes.
If you want data guarantee this paper (http://www.google.com/url?sa=t&rct=j&q=ext4%20data%20checksum&source=web &cd=4&ved=0CDgQFjAD&url=http%3A%2F%2Fpages.cs.wisc .edu%2F~bpkroth%2Fpapers%2Fext4parity.pdf&ei=yGi8T qvrL-n40gHrtMnABA&usg=AFQjCNEWwXXtsREjCYjMCQYa65S9GZFp1 A&cad=rja) indicates that changes to the MD layer should provide the type of data guarantees zfs has while maintaining the separation of duties of a file system driver from the io layer.
Regarding btrfs being slow it SEEMS as if it would only be slow when writing, but due to the extra work involved with finding good layout schemes when writing, reading should be quite fast. I'd be interested in seeing the some phoronix benchmarks of a mostly full fs when using both btrfs and ext4.