A New Linux File-System Aims For Speed While Having ZFS/Btrfs-Like Features

[kebabbert]

That's nonsense. Designing an uber-reliable filesystem is not any harder than designing a super-fast filesystem. The challenge is to design a filesystem that is reliable AND fast.

*not* ZFS, because in may scenarios its performance is indeed far less than Acceptable.

You are ignorant. It is very very difficult to design a reliable filesystem, as CERN explains in my link. They say that even very expensive enterprise storage servers get data corruption, in a research paper. First of all, you MUST have a monolithic filesystem, controlling the entire storage stack. You can nor have a separate filesystem, separate volume manager, separate raid system, etc. That is inherently unsafe (read my link on part "data corruption"). If bcache is a separate filesystem, it is toast you can say for sure. Zfs is monolithic, and that is why it is safe.

Second, zfs scales to 55petabyte installations, with 1tb/sec bandwidth at sequioua super computer centre, i would not call it slow.

[kebabbert]

You can't compare 2 things if you only know 1. Also I'm not sure why you don't consider reliability a feature but it would help with your confusion if you did. BcacheFS was just announced and is still in an early testing level release phase so of course you're not going to find it in much filesystem reliability research if any at all but if you actually read about it before you complained the author is wrong you'll find BcacheFS either already does or plans on supporting all of those things you linked to why ZFS is so reliable. It's goal is just to do it faster.

I meant that he considers ext4 and xfs reliable, well, they are not as proven by comp sci researchers in my link i posted earlier. Ext4 is unreliable so why aim for ext4 "reliability"? Zfs is reliable, he should aim for zfs reliability, not for ext4 which is proven unreliable

[GreatEmerald]

Hmm. Yes, I still don't think anything beats having / on SSD and /home on HDD when it comes to responsiveness and boot times.

[kernelOfTruth]

I want both and that is indeed what I have. My root is an SSD with btrfs while my /home consists of two spinning disks in a zfs mirror. Best of both worlds, fast access for files I can easily replace and safe storage for my personal data.

++

works fine here and haven't any data issues so far *knock on wood*

(except of course the self-induced by tinkering with filesystem )

[Staffan]

"...match ext4 and xfs on performance and reliability, but with the features of btrfs/zfs..."

This is retarded. The only point of using ZFS is it's reliability, nothing else comes close. There are research on ZFS showing that it is the most reliable data protecting filesystem out there today. Everything else, snapshots, scalability to Petabyte raids, performance, etc are just not important. The main point of a filesystem is to be reliable. If it can not protect your data against bit rot and other forms of data corruption, does it matter if it is very fast? What do you choose, a fast and unreliable filesystem or a slow but a reliable filesystem? I dont care how fast a filesystem is, I want my data protected. There are research on ext4 and xfs showing they are unreliable, and there are research showing that ZFS is reliable. The author got it backwards, ZFS is the only proven reliable filesystem by researchers, ext4 and xfs are not:
https://en.wikipedia.org/wiki/ZFS#Data_integrity

I want both and that is indeed what I have. My root is an SSD with btrfs while my /home consists of two spinning disks in a zfs mirror. Best of both worlds, fast access for files I can easily replace and safe storage for my personal data.

[Mike Frett]

I'm seeing a new trend from Linux users. Apparently they're getting tired of seeing another new file system or another new distro. So why not dedicate the resources used on things nobody will use and use them on existing projects that everyone uses! Wow, amazing...

I'm kidding. Do whatever you want bro. More power to ya =p

[waxhead]

I like to see a storage system where you set attributes (fast, super fast, normal, redundant, lazy, super redundant, etc.) on a file or directory. And if these beast needs physical storage should drop me a message. Also it should gives some power and noise controlling options by shutting down physical media.

Just dreaming.......

As Jacob said this is planned and in the works for btrfs. Some time ago I also wrote a suggestion for a "supercache" for btrfs - let me explain: Ideally the filesystem should be able to relocate hot (often used) data on a portion of the fastest disk(s). So if you have a 18 disk raid 6 for example you can reserve a portion of this disk for a "supercache". The "supercache" could be raid0 e.g. striped across all disks. Since the "supercache" is already duplicate of the hottest data located elsewhere on the array it can always fetch the original data even if you loose a disk or data get's corrupted. This would be very fast for reads, and for writes the "supercache" could use raid10 that should give you some redundancy even before the written data is duplicated on the primary (raid6) part of the filesystem.
I think that at some point in the future most "pooled" multi device filesystems will end up doing something like this.

[_ck_]

Is it possible for the test suite on Phoronix to add the "max latency" as part of the benchmarks like Kent does?

Because it makes EXT4 stand out and look rather good, especially when all other numbers are rather close.

[xeekei]

I don't like the name, but I like the goal. That's the most important part.

[peppercats]

Raw performance is nothing, I only use f2fs for ssd systems anymore. Ridiculously lower latency.