Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    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.......

    Comment


    • #12
      Originally posted by dibal View Post
      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.......
      Not dreaming. It already works that way in btrfs: cow/noncow, compression algorithm etc. per file or directory. I've read that they even plan per-file raid settings but I don't know if/when that will be supported.

      Comment


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

        Comment


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

          Comment


          • #15
            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.

            Comment


            • #16
              Originally posted by dibal View Post
              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.

              http://www.dirtcellar.net

              Comment


              • #17
                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

                Comment


                • #18
                  Originally posted by kebabbert View Post
                  "...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.

                  Comment


                  • #19
                    Originally posted by Staffan View Post


                    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 )

                    Comment


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

                      Comment

                      Working...
                      X