Btrfs Picks Up Snappy Compression Support

[FourDMusic]

I've already said less articles is not viable in a business sense.

I'm sorry to hear that. Thanks for all your hard work!!! I've learned a lot from your articles and the phoronix forums

[devsk]

What's the use of features when the filesystem leads to corruptions without power loss? I had been bitten by BTRFS corruption, and mind you, the FS has to be remade, there is no recovery. But given how much work has gone in 3.2, I thought I will give it a try. Another corruption was hit today after 5 days of uptime.... /usr/src/linux developed "stale NFS handles" with files having ???? for attributes. updatedb caught the corruption because it could not go beyond it.

We are still in 2008 wrt to stability of this FS.

[geearf]

I have been using btfs for quite some time with no issue.
Only when using *bad* kernel modules did I have issues, and I had the same with ext4 anyway...

[cb88]

Better articles = more readers = more page views = profit. Its pretty simple... take for instance how japan took off after realizing people really didn't want to buy broken crap and wanted a certain level of quality.

What is the point of paying for a premium Phoronix account if the articles are quite frankly tasteless.

[AnonymousCoward]

Better articles = more readers = more page views = profit.

Possibly more relevant example: http://lwn.net/Articles/471250/

[evergreen]

Better than Snappy ?

Since you are evaluating better alternatives to LZO,
you may also have a look to LZ4.

It's apparently faster than Snappy,
while being a plug&play replacement, according to the Apache team which has adopted it for Hadoop.

https://github.com/decster/jnicompressions