Slashdot Mirror

← Back to Stories (view on slashdot.org)

Meet Linux's Newest File-System: Bcachefs

Posted by Soulskill on from the my-compliments-to-the-bcachefs dept.

An anonymous reader writes: Bcachefs is a new open-source file-system derived from the bcache Linux kernel block layer cache. Bcachefs was announced by Kent Overstreet, the lead Bcache author. Bcachefs hopes to provide performance like XFS/EXT4 while having features similar to Btrfs and ZFS. The bachefs on-disk format hasn't yet been finalized and the code isn't yet ready for the Linux kernel. That said, initial performance results are okay and "It probably won't eat your data — but no promises." Features so far for Bcachefs are support for multiple devices, built-in caching/tiering, CRC32C checksumming, and Zlib transparent compression. Support for snapshots is to be worked on.

84 of 132 comments (clear)

  1. Mrs Overstreet? by TechyImmigrant · · Score: 4, Funny

    If there's a Mrs Overstreet, she needs to be careful. Linux FS programmers have a bit of a history.

    --
    I should use this sig to advertise my book ISBN-13 : 978-1501515132.
  2. Like the DragonFly BSD approach? by lambsonic · · Score: 2

    Is this the Linux answer to swapcache and the HAMMER filesystem in DragonFly BSD? Of course, a major generalization and oversimplification, but it seems a similar kind of approach to a similar set of problems.

    --
    # make clean sig
    1. Re:Like the DragonFly BSD approach? by Anonymous Coward · · Score: 5, Interesting

      Definitely not like HAMMER. Every new filesystem in the past 15 years has used b-trees. You have to because traditional block tables don't scale to the huge disks we have today. (At least, that's the conventional wisdom.) Copy-on-write follows naturally from using a b-tree data structure. So that's definitely not new, either.

      HAMMER has so many other design goals that bcachefs isn't even in the same league. For one thing, HAMMER supports online multi-machine replication. HAMMER2 will support multi-master replication.

      And unlike all the other Linux filesystems in development, HAMMER (1) actually exists in final form and (2) is stable. The last useable b-tree based filesystem that emerged from the Linux world and gained any traction was ReiserFS, which officially released in 2001. XFS is the most widely used b-tree FS on Linux, but it originated at SGI on IRIX in 1993.

      bcachefs looks dead in the water to me. It currently doesn't match the performance of ext4. The author claims there's plenty of room for improvement. Well, of course there is for any proof of concept. But there's also a crap-ton of work to do for correctness and recovery. Correctness and recovery is the achilles heel of b-tree based file systems. Making b-tree filesystems performant while keeping them robust is extremely difficult. What differentiates all the contenders are the way they approach optimization, correctness, and recovery. The strategies invariably evolve to become extremely complex--both the design and the code. bcachefs hasn't appeared to even scratch the surface in that regard.

      The optimism of the author suggests to me extreme naivety. I wouldn't touch anything he writes with a 10-foot pole.

    2. Re:Like the DragonFly BSD approach? by buchner.johannes · · Score: 1

      I can't find it now, but somewhere on the NameSys website they had an interesting piece on what made them so successful in writing a fast filesystem.

      Essentially, and I am quoting from memory now, classical file system codes start with a grand idea of what *should* be a fast architecture (e.g. B/B+/dancing trees, etc.), then code that in all at once until perfection, and finally benchmark the finished product.
      In contrast, they would try an implementation of a feature, then quickly benchmark it on several file systems for performance, then try another implementation. Because they had a quite flexible code base, they could do this write-test-rewrite cycle very quickly, and converge on the best solutions through experiments. That was their secret sauce. Perhaps all FS code has to become more playable for key advances.

      Then also they developed this plugin architecture with which you can activate and exchange various features of the FS. Well, Linux developers really didn't like that because it looks complex and is unlike any other FS in Linux.

      --
      NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
  3. Re:Another one? by phantomfive · · Score: 1

    There isn't a really great filesystem available for Linux (ext4 can lose data).
    That's why I support any team that wants to try to write a better one. Please don't kill your wife, though.

    --
    "First they came for the slanderers and i said nothing."
  4. Why? What advantages does this have over ZFS? by UnknownSoldier · · Score: 4, Insightful

    > a modern COW filesystem with checksumming, compression, multiple devices, caching, and eventually snapshots and all kinds of other nifty features

    Instead of yet another FS flavor of the month, or year, (Reiserfs, Btrfs, Bcachefs, etc.) and all the man-hours wasted re-solving the same old problems how about just doing it right the first time (ZFS) ?? Because this is what it is turning into. What advantages bachefs have over ZFS??? There is no way in hell I'm going to trust an unproven, buggy, and incomplete FS when we already have one that works.

    Fixing the Butr free space shenanigans would have been a step in the right direction: An existing debugged FS.

    Reminds me of this xkcd #927: Standards

    1. Re:Why? What advantages does this have over ZFS? by Trepidity · · Score: 1

      Is ZFS-on-Linux production ready yet?

      --
      10 PRINT CHR$(205.5+RND(1)); : GOTO 10
    2. Re:Why? What advantages does this have over ZFS? by Anonymous Coward · · Score: 3, Informative

      Yep, just not included in standard distros due to licensing.

    3. Re:Why? What advantages does this have over ZFS? by rubycodez · · Score: 2, Informative

      You are funny, ZFS is a horrible resource pig. Many superior alternatives exist

    4. Re:Why? What advantages does this have over ZFS? by danbob999 · · Score: 1

      License, maybe? And then performance, as said in TFS.

    5. Re:Why? What advantages does this have over ZFS? by danbob999 · · Score: 2, Informative

      BTRFS is more ready than ZFS is. It is already pretty stable, in the kernel, and distros are talking about using it as a default FS.
      The main problem to its adoption is that most people don't need the extra features over ext4 and don't really care.

    6. Re:Why? What advantages does this have over ZFS? by Anonymous Coward · · Score: 1

      COW

      Moooooo?

    7. Re:Why? What advantages does this have over ZFS? by Anonymous Coward · · Score: 5, Funny

      Wrong. If you have enough RAM (about 4x what you would normally estimate you need) and a fast enough CPU and keep your storage pool small, then it is not a hog. I wish people here would stop trying to mislead us about ZFS.

    8. Re:Why? What advantages does this have over ZFS? by Anonymous Coward · · Score: 1

      "Pretty stable"? That's a standard? I don't know about you, but a FS is either stable or it's not. If it loses your data only sometimes, it is not "pretty stable" the rest of the time.

    9. Re:Why? What advantages does this have over ZFS? by Anonymous Coward · · Score: 1

      So... it's a horrible resource pig.

    10. Re:Why? What advantages does this have over ZFS? by Anonymous Coward · · Score: 1

      Both ZFS and btrfs have buglists a mile long. I wouldn't say either one is "working" yet.

      Personally I only used btrfs and while it hasn't lost me data yet, I found it easy to deadlock and a horrible disk space hog over time. But friends at companies that tried going with ZFS on Linux were similarly unimpressed by it.

    11. Re:Why? What advantages does this have over ZFS? by Harlequin80 · · Score: 1

      If you are running ZFS on a raspberry Pi you will see massive performance degradation on anything that causes a write. ZFS is very heavy on using ram for cache and will disable sections of its functionality and hugely throttle writes when there is only a small amount of ram present.

      To put this into a real life example, Freenas will disable cache read and write for ZFS if you have less than 4gb of system ram.

      There isn't anything stopping you running ZFS on the Pi but your performance will suck.

    12. Re:Why? What advantages does this have over ZFS? by kthreadd · · Score: 1

      So, how did I manage to run ZFS on fairly old and underpowered Solaris servers without performance problems almost ten years ago? Did the Linux guys somehow break the whole thing as they ported it to Linux?

    13. Re:Why? What advantages does this have over ZFS? by Anonymous Coward · · Score: 5, Informative

      You know that www.phoronix.com lost data due to BTRFS recently? The author, Michael, wrote an article on the corrupted data using BTRFS this month. He deemed it not to be production ready. And if you read the forum comments on the article, lot of people wrote that they also got corrupted data due to BTRFS. Not production ready.

    14. Re:Why? What advantages does this have over ZFS? by Guspaz · · Score: 1

      Which is a fair criticism, but ZFS was designed for use in modern desktop and server computers, not embedded devices with tiny amounts of RAM. This was no secret, when they designed ZFS they clearly stated that they wanted to take advantage of the resources available in modern computers, whereas most existing file systems had been designed when computers had far more limited resources.

    15. Re:Why? What advantages does this have over ZFS? by tlhIngan · · Score: 1

      Wrong. If you have enough RAM (about 4x what you would normally estimate you need) and a fast enough CPU and keep your storage pool small, then it is not a hog. I wish people here would stop trying to mislead us about ZFS.

      That seems to limit its usefulness. I mean, ZFS typically wants 1GB of RAM per TB of storage. And ZFS makes perfect sense for large storage NAS tasks.

      But that also means that since commodity processors have a 32GB RAM limit (slightly lower thanks to peripherals), that limits you to 32TB of storage, or maybe you can push it to 64TB. Granted, the latest and greatest from Intel support 64GB of RAM but I can see upgrading hard drives in a NAS far more often than upgrading the CPU which is probably way more powerful than you need for serving up files. Maybe to serve up multiple high-def streams on something like Plex (which will transcode on the server if there's power).

      And no, 32TB of storage isn't unachievable.

    16. Re:Why? What advantages does this have over ZFS? by Anonymous Coward · · Score: 5, Informative

      Yeah, that clearly was die to BTRFS, totally unrelated to running a git master kernel.
      Not 4.2.x.
      Not 4.2.
      Not 4.2-rc.
      Linus' git master.
      In production.

    17. Re:Why? What advantages does this have over ZFS? by rubycodez · · Score: 1

      You won't be hooking 4TB of storage to that 4GB server and running ZFS under load

    18. Re:Why? What advantages does this have over ZFS? by Harlequin80 · · Score: 1

      I think ZFS is perfect for the server environment, I run it there myself. I was commenting on ACs running it on a Pi.

      I'm not sure that ZFS is the best solution for a desktop though. But that may be because of how I envisage desktop usage. To me ZFS' biggest strengths lie in its raid-z and checksumming capabilities and how that is used to protect your data on a dedicated data storage system. I'm not sure I see any advantages to having ZFS as the file system on a single drived desktop or laptop however.

    19. Re:Why? What advantages does this have over ZFS? by oakgrove · · Score: 1

      Um, woosh?

      --
      The soylentnews experiment has been a dismal failure.
    20. Re:Why? What advantages does this have over ZFS? by fnj · · Score: 2

      NO WAY is btrfs even in the same class of reliability and robustness as ZFS. So no, it is NOT production ready. And no, I won't be easily impressed just because some dopey distros take a chance on it.

    21. Re:Why? What advantages does this have over ZFS? by fnj · · Score: 2

      I am running every day 36 TB of raw storage - 24 TB after redundancy is subtracted - in two 6-drive RAIDZ2 ZPOOLs on a CentOS6 box with 8 GB of RAM devoted to ZFS (total installed RAM is 16 GB). Both pools are nearing 90% full. Performance is excellent and problems nil. So you can push well past the 1 TB/GB rule of thumb.

      Yeah, if you traverse the entire system listing files, it's a little slow because my RAM ARC cache is so limited, and I have no SSD L2ARC cache. That's an acceptable tradeoff for my purposes.

      I have some directories being snapshotted every 5 minutes. The last 24 5-minute snapshots, 48 hourlies, 62 dailies, and 8 weeklies are currently preserved online. 9 of the 24 provisioned monthlies are there; that's how long I've been running the cron job; and no yearlies so far. Snapshots older than 24 5-minute/48 hourly/62 daily/8 weekly/24 monthly are auto-trimmed.

      Altogether I can enumerate in real-time (essentially instantly) 607 directory-hierarchy snapshots (sum of number of directory hierarchies snapshotted times number of snapshots in existence for that directiry hierarchy).

    22. Re:Why? What advantages does this have over ZFS? by thegarbz · · Score: 1

      That seems to limit its usefulness. I mean, ZFS typically wants 1GB of RAM per TB of storage.

      And more again if you do de-duplication, but there's one key thing that is missing from the discussion: If you keep ZFS happy with loads and loads of RAM to cache then it far outperforms filesystems with comparable feature sets, and even out performs simpler file systems like EXT3/4 on some metrics like doing random I/O on spinning disks.

      Throwing 16GB of RAM at EXT3/4 won't make it any faster, but on ZFS it will, and it would seem that not offering enough RAM for the entire cache only has a minor performance hit when you access a LOT of files in a LOT of different directory trees at once, think system backup.

    23. Re:Why? What advantages does this have over ZFS? by mcrbids · · Score: 2

      Disclaimer: I ZFS.

      We had a problem that ext* just couldn't handle. We have a medium sized filesystem with about 250 million data files that we needed to back up. Every day. Rsync completely failed at the job, taking between 1 and 2 days to do the job.

      Desperate to find a solution, we tried ZFS and snapshot replication. Our time to replicate to DR, dropped from days to a few hours, backup storage requirements dropped through the floor, and server load dropped at the same time! This is on a reasonably priced set of systems, Xeon-based intel systems with just 32 GB of RAM and 6x 4 TB drives.

      ZFS is pretty decent, and has proven to be more reliable for our use than ext*. However, its licensing presents a developmental pit fall. On Linux, it won't ever be a "first rate citizen" even though the ZoL project has done a great job making it very available. ZFS also has a number of pretty terrible problems:

      1) You can't remove a vdev from a ZFS pool without destroying the pool.

      2) You can't upgrade a vdev's redundancy level once you've added it to a pool.

      This means that, if you're careful, ZFS is wonderful. But it's easy to make a mistake that you can't easily back out of. See the section hating your data to see what I mean.

      BTRFS has been "only a few years away now" for quite a few years now. I'm not convinced it will ever reach production ready status. Apparently it has some architectural problems that have been criticized pretty soundly. I'm no longer convinced about the future inevitability of BTRFS.

      I sincerely hope that BCacheFS really delivers on these promises, I'd love it!

      --
      I have no problem with your religion until you decide it's reason to deprive others of the truth.
    24. Re:Why? What advantages does this have over ZFS? by ToasterMonkey · · Score: 1

      You are funny, ZFS is a horrible resource pig. Many superior alternatives exist

      Yup, boy did Sun call that one wrong, because spare processing & memory capacity haven't been steadily rising since ZFS's introduction at all, have they...

    25. Re:Why? What advantages does this have over ZFS? by ToasterMonkey · · Score: 1

      You won't be hooking 4TB of storage to that 4GB server and running ZFS under load

      Modern servers, even desktops have so much extra capacity it's not even worth hesitating to turn on all sorts of background services these days. Configuration management, integrity checking, backups, compression, encryption, software dedup, we don't think twice about this stuff anymore.

      High capacity, high load, small working set size, minuscule physical memory, and a local filesystem... where is that combo in the real world?

      A real system where ZFS is too "bloated" to use would mean I'd be afraid to install a backup agent or run Puppet on it. This all seems very contrived.

    26. Re:Why? What advantages does this have over ZFS? by SuricouRaven · · Score: 1

      A filesystem does not need to be good enough to trust absolutely, because no filesystem should ever be trusted absolutely.

      You just need to be confident that the chance of a fault is low enough that you can accept the amount of downtime it will take to restore from your backups. Which, I hope, are taken often and stored on independent physical media.

    27. Re:Why? What advantages does this have over ZFS? by blackpaw · · Score: 1

      Me to, I'd love to know these alternatives too, since I'm setting up extra storage for a VM Cluster. The checksumming is a must. Easy addition of drives for mirrors and spanning as well. Simple integration of SSD caches too. And a large set of logical easy management tools.

    28. Re:Why? What advantages does this have over ZFS? by blackpaw · · Score: 1

      I forgot to mention transparent and fast compression, that actually speeds up disk reads/writes.

    29. Re:Why? What advantages does this have over ZFS? by Bert64 · · Score: 2

      Because your fairly old and underpowered solaris servers likely had small disks...

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    30. Re:Why? What advantages does this have over ZFS? by Bert64 · · Score: 1

      You're also limited by a slow 100mbit nic, and USB for storage, so the filesystem isn't the bottleneck... Most lowend NAS devices come with gigabit nics these days.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    31. Re:Why? What advantages does this have over ZFS? by rl117 · · Score: 1

      Nonsense. Btrfs is still not reliable. I've lost data from it twice when it trashed the filesystem irrecoverably, and more recently I've been suffering from the need to periodically rebalance. Where periodically is "approximately every 36 hours" under high load. I'm afraid that a filesystem which randomly stops working every 1.5 days because it used up all the free space (despite the disk being under 10% full) is most emphatically *not* production ready by any stretch of the imagination. Even FAT was more reliable than this. The bugs causing dataloss may have been resolved now, but the unbalancing is not and is a major blocker--how can you rely on a filesystem which can stop working unpredictably. You can't by definition.

      ZFS on the other hand *is* production ready, and has been in production for years on serious hardware.

      The poor state of Linux filesystems is what drove me to ZFS on Linux, and later migrate the pools to a FreeBSD fileserver--as simple as transferring the disks and importing the pool. Btrfs has been "almost ready" for years but has never yet reached the point where it's genuinely guaranteed reliable. I think the distributions which hopped onto the Btrfs bandwagon are fools, and their users will be the ones to suffer.

    32. Re:Why? What advantages does this have over ZFS? by rl117 · · Score: 1

      This may be the case, and the experiences of Phoronix are certainly "higher profile" than the rest of us. However, the reality is that it's been awful in all the stable kernel releases as well. Maybe not this bug, but unbalancing and occasional dataloss have been a common experience for many people, including myself.

    33. Re:Why? What advantages does this have over ZFS? by swb · · Score: 1

      I've only played with it a little via nas4free (which probably limits what I know further), but what would have seemed to make more sense to me would be just add disks/LUNs to the pool without any specific redundancy assignments and create vdevs as device block-level parity sets across all pool members.

      These virtual vdevs could be restriped on demand to change RAID levels and adding a disk to the pool would cause it to rebalance the stripes across all pool members. Removing a disk would be the opposite, provided you had enough pool capacity and devices to support the stripe level. In theory, a virtual vdev should be something you could then move between pools.

      It's hard to escape limitations, but obviously mixing RAID levels in a pool would have some performance penalty if you had a busy parity vdev while trying to use a mirror or simple stripe for performance, but I think this is where you wave your hand about having enough devices/IOPS in your pool or create dedicated pools.

      From my exposure to commercial SANs, many do things this way. Compellent block-level stripes RAID-10 and RAID-5 across disk pools (in training, they never explain why there's no performance penalty or why there's a performance benefit to block level striping, but IIRC they dedicate RAID-10 for writes and move them to RAID-5 for reads and don't want you to dedicate a RAID level to your volumes).

      Equallogic members only have one RAID level, but you can pick what RAID level you use for the member. Adding members to the same pool balances all volumes across all pool members based on performance. You can also create separate pools and add members to individual pools and volumes can be moved between pools.

    34. Re:Why? What advantages does this have over ZFS? by danbob999 · · Score: 1

      NO WAY is btrfs even in the same class of reliability and robustness as ZFS.

      We are talking about ZFS for Linux. Not ZFS in general.

    35. Re:Why? What advantages does this have over ZFS? by dinfinity · · Score: 1

      That's a terrible argument.

      The fact that we've had crappy storage systems in the past that mandated backups is no reason to state that it should always be like that.

      A good file system(tm) should protect against the weaknesses of the underlying physical media, it should provide snapshots, it should provide (configurable) redundancy, and it should support geographically separated redundancy.

      Especially the last one is very much a work in progress for the DIY-self-sufficeint-user, but we should and will get there in the very foreseeable future. Services like Amazon S3, Bittorrent Sync, technologies such as Tahoe-LAFS ( https://en.wikipedia.org/wiki/... ) and ZFS show the direction in which we're going. That direction is one in which (incremental) backups exist by default, disk failure is easily overcome and even a data center being blown up does not cause data loss.

      Clinging to our old ways is safe and wise in many environments (better the devil you know), but considering it to be the norm for the future is just silly.

    36. Re:Why? What advantages does this have over ZFS? by dinfinity · · Score: 1

      You can explicitly mark (parts of) the pool as being duplicated (copies=x), which gives you the checksumming capabilities (but reduces your max storage space, obviously):
      https://blogs.oracle.com/relli...

      I have a server I use mainly for remote backups of my important data. It has a single 3GB disk for the data in a ZFS-pool with copies=2 for the entire pool. With deduplication disabled and regular snapshotting and scrubbing enabled, it gives me a good amount of security on the availability of my data.

      (Yes, I am acutely aware that I should have installed at least one other disk, but I had already put the server in its remote location when I started to get into setting up ZFS. I'll get around to it some time)

    37. Re:Why? What advantages does this have over ZFS? by Bengie · · Score: 1

      Not the driver, that's a divide-by-zero in a bash-script that only happened when there were 0 reads from the L2arc, which can only happen during a brief window after the system starts up.

    38. Re:Why? What advantages does this have over ZFS? by Bengie · · Score: 1

      A well designed FS should not allow for committed data to be lost. A correct design results in a very binary state, either things work or they don't. If they work, you don't lose data, if they don't work, it immediate errors out instead of chugging along and corrupting data.

      Of course this is ideal and not 100% attainable, but you can get really damned close. Fail early and fail with a clear error message with the exact reason. All reasons should be accounted for.

    39. Re:Why? What advantages does this have over ZFS? by Bengie · · Score: 1

      You can configure ZFS to only cache metadata in memory. Out of the box, ZFS comes configured for servers with at least 8GiB of memory. You can tweak it to be decent on low end hardware, but it really isn't meant for embedded systems.

    40. Re:Why? What advantages does this have over ZFS? by Bengie · · Score: 1

      The problem with ZFS is the only way to rebalance vDevs or removing them is to do pointer re-writing, and pointer re-writing by definition leaves the FS in an inconsistent state during the transition, and they refuse to do anything that leaves the FS in an inconsistent state. What they need is a way to atomically update all references that point to a a data block. There are some ways to do this, but the cure is worse than the disease. It's simpler to just make a duplicate system with your corrected vDevs and replicate the data over to them.

      They actually did find a work-around to removing a vDev. Make a virtual vDev that is backed by the remaining vDevs, replicate that to-be-removed vDev to that virtual vDev, then remove the one vDev. I don't know when/if this will be implemented, but one of the original engineers who designed and programmed ZFS back with Sun who is still a contributing member to OpenZFS, said this is doable.

      With my limited understanding, you may be able to change a vDev's raid type with this new feature. If you can clone a vDev without cloning the entire pool, you could in theory write the data to a vDev with a different raid level. You just can't do in-place raid level changes.

    41. Re:Why? What advantages does this have over ZFS? by Bengie · · Score: 1

      Native flash support isn't a huge selling point. A simple IO layer like FreeBSD's GEOM can handle that. They're two distinctly separate issues with virtually no benefit of integration. Similar thing with encryption and ZFS. OpenZFS has decided to forgo encryption because layers like GEOM can handle the encryption just fine and has the benefit of being useful for other file systems as well and reduces the work, complexity, and chance of bugs for OpenZFS. There are some benefits to ZFS directly supporting encryption, but they're corner cases and more useful as a check-box for policy requiring such features than needing such features.

    42. Re:Why? What advantages does this have over ZFS? by Bengie · · Score: 1

      How does that help if you want to boot off of ZFS?

    43. Re:Why? What advantages does this have over ZFS? by phoenix_rizzen · · Score: 1

      No, with dedupe enabled, ZFS runs best with 1 GB of ARC space (including L2ARC) for every TB of unique data in a pool.

      With dedupe turned off, all data is unique, but then you need less ARC to manage it.

      We have a couple of 40 TB pools running with only 32 GB of RAM without issues.

      We also have a couple 96 TB pools running with 128 GB of RAM; one even has dedupe enabled and runs without issues.

      And I've run it at home on a P4 system with only 2GB if ram without issues. Nursing from raidz1 using 160G drives, to raidz1 with 250G drives, to multiple mirror vdevs with 500G drives. Then from 32-bit FreeBSD to 64-bit FreeBSD, and finally to 1T drives (4 GB RAM). That's also my home desktop, Plex server, file server, etc).

      You don't *NEED* a lot of ram to run zfs. But it will run better if you can add more into a system.

    44. Re: Why? What advantages does this have over ZFS? by swb · · Score: 1

      I can't remember the class details, but I think the Compellent defaulted to 5 and 10 (10 for writes, 5 for reads) although I think there were ways to define specific volumes as double parity (aka 6) and double mirroring, although IIRC there was some penalty beyond just extra disk consumption.

      The Equallogics will do 5, 10, 50 and 6. 5 supposedly is not recommended for NLSAS and SATA disks over 1 TB due to risk of secondary disk failures during a rebuild and I'd swear the SSD caching models only allow 6. 10 almost never gets used unless the customer asks for it explicitely or they bought such a giant amont of disk space that 10 would accomodate their needs for the near term and they were willing to restripe which the EQLs will do online. Older units repuporsed often get 10 to crank up performance a little, although dual 1 GB ethernet is the real bottleneck.

      IIRC 50 and 6 end up being pretty close in capacity and that's what most devices end up formatted as because customers always need maximum capacity -- sales and marketing throw around unformatted capacity numbers, and customers don't account for redundancy formatting, snapshot space and so on.

    45. Re:Why? What advantages does this have over ZFS? by fnj · · Score: 1

      Not the driver, that's a divide-by-zero in a bash-script that only happened when there were 0 reads from the L2arc, which can only happen during a brief window after the system starts up.

      There is another way it "might happen". You might not HAVE an L2ARC. I had to fix that nasty script on my system.

    46. Re:Why? What advantages does this have over ZFS? by fnj · · Score: 1

      We are talking about ZFS for Linux. Not ZFS in general.

      So am I. Point?

    47. Re:Why? What advantages does this have over ZFS? by Burz · · Score: 1

      And unfortunately, Michael completely decided not to help the Kernel devs debug this issue, because he was losing money on his benchmarks anyway. Let's disregard the fact he was a step beyond the packages on kernel.org

      Interesting. I also have to wonder how close to either 'production' or 'personal use' Phoronix labs can get. These are people who pick and tear things apart and assemble in odd ways (nothing that a person wandering the computer aisle of Staples would recognize).

      FWIW, I've been using a Qubes desktop on top of Btrfs for over 4 months now with very heavy usage. There have been no problems with the filesystem thus far (knock on keycaps... :). In terms of features, Btrfs is a flexibility dream. Using reflink copy I can clone VM images and other files instantly with hardly any overhead, and its great for small/informal snapshots of data.

    48. Re:Why? What advantages does this have over ZFS? by rubycodez · · Score: 1

      actually that combination with undersized memory or cpu resources VERY common in world of virtualized servers, with miserly admins.

    49. Re:Why? What advantages does this have over ZFS? by rubycodez · · Score: 1

      and then you'd find ZFS needing over 5GB with 2.5GB left for your apps and OS

    50. Re:Why? What advantages does this have over ZFS? by danbob999 · · Score: 1

      ZFS for linux is nowhere nears production ready. It isn't even in the kernel (and never will, because of license)

    51. Re:Why? What advantages does this have over ZFS? by rubycodez · · Score: 1

      virtualization has become HUGE since Sun introduced ZFS, and in that scenario memory and cpu are very cafefully rationed resources. Thus ZFS becomes an unwanted resource pig

    52. Re:Why? What advantages does this have over ZFS? by rubycodez · · Score: 1

      Those are done outside of the host in enterprise production systems as part of SAN disk solutions

    53. Re:Why? What advantages does this have over ZFS? by lewiscr · · Score: 1

      As a long time ZFS admin, I have a few suggestions.

      ZFS snapshots and send are much faster than rsync. Nearly all of them time is spent actually transferring data, and very little is spent enumerating data. One day it dawned on me that I could do hourly, or even 5 minute, snapshot && send on machines that could only handle daily rsyncs on ext4. It still depends on your write bandwidth and overwrite percentage, but it removes number of files from the equation.

      Regarding vdev reorganization, it's true, you can't really change vdevs in an existing pool. I got around that by destroying the zpool on the backup server, re-creating it the way I wanted, then zfs sending the FS over again. The actual failover process is part of the manual failover setup anyway, so flipping cost me less than a minute of downtime. Let it burn in for a few days, then rebuild the original server's disks.

      One last thing it took me a while to figure out. RAID-Z is faster than RAID10. Even for your IO bound processes, like PostgreSQL or MySQL. I'd done so many benchmarks showing that hardware RAID10 was better than hardware RAID5 for IO load, that I didn't even think about re-testing that conclusion under ZFS. Much later, I noticed that my storage servers (RAIDZ) could handle more IO than my database servers (RAID10). A 4 disk RAIDZ was faster than a 4 disk RAID10, and a 4 disk RAIDZ2 was the same speed. And I had 5 bays for spinners, so I could actually do a 5 disk RAIDZ vs a 4 disk RAID10 (8 bays total, including 3 for mirrored ZIL + L2ARC). As always, your benchmarks will vary. Just don't forget to re-test conventional wisdom.

  5. Re:Good job by rubycodez · · Score: 1

    Maybe your goals aren't shared by anyone that actually writes the OS or applications for Linux. Who cares what windows twats do?

  6. Gesundheit! by Nexion · · Score: 1

    :P

  7. It has a cool purpose... but perhaps encryption? by mlts · · Score: 1

    I like the idea this filesystem is going for... it can be useful as a cache, so that hardcore random I/O is smoothed out before it goes onto HDD platters, so a SSD can function as a place for the OS, and as a cache between a drive array or slow external drives.

    My only addition would be encryption. If it is designed to work as a transient, ephemeral filesystem where data is only kept until it is safely copied to the real filesystem, then maybe encryption should be a part of this, with keys for data periodically changed out to ensure that data already written to the HDD is not going to be recovered, or if the cache is used as a read cache, the key would reside in RAM and the cache rebuilt on reboot.

  8. Re:Bca-chefs are for cows by phantomfive · · Score: 1

    He actually got modded up in the systemd thread.

    --
    "First they came for the slanderers and i said nothing."
  9. Tux3 FTW by Anonymous Coward · · Score: 1

    Has better durability, semantics, and outperforms ext4 in most tests and even tmpfs in a few.
    Eagerly awaiting mainline merge--waiting for mostly politics to resolve, or so it seems.

  10. Funding Needed by bezenek · · Score: 3, Interesting

    From Mr. Overstreet's announcement:

    PSA: Right now I'm not getting any kind of funding for working on bcachefs; I'm
    working on it full time for now but that's only going to last as long as my
    interest and my savings account hold out. So - this would be a wonderful time
    both for other developers to jump in and get involved, and for potential users
    to pony up some funding. If you think this is interesting and worthwhile and you
    want to see it completed and upstream - especially if you're at a company that
    might make use of it - talk to your $manager or whoever and nag them until they
    send me a check :)

    --
    Omne ignotum pro magnifico.
    1. Re:Funding Needed by John+Bokma · · Score: 1

      Please sponsor my hobby ;-)

      --

      Perl Programmer for hire
    2. Re:Funding Needed by DidgetMaster · · Score: 1

      Good luck with that. Nobody seems to want to pay for system level software anymore. They might shell out a few bucks for a game that they will grow tired of after a few weeks, but they expect their OS, tools, and other platform software to be free (as in beer). You might build a system, library, or algorithm that collectively saves the world economy a $ billion dollars per year in saved time, electricity costs, and/or hardware upgrades; but don't expect to get paid anything for doing it. Sad as that might be, it seems to be the reality we currently live in. For the past few years I have been building a new data management system that blows the doors off a bunch of file systems and databases in terms of performance, but I can't get anyone to fund any of it. They all have the same reaction to the demo of my partially working system..."That is amazing. Let us know when the development is complete and tested in an enterprise environment and we will use if we can have it for free" (as if I had a bunch of magic slave elves coding for me all night in my basement in order to accomplish those things without any resources).

    3. Re:Funding Needed by DidgetMaster · · Score: 1

      On the contrary....I have had several people tell me it is something they need. They wish it was finished right now. But for whatever reason, they won't put any resources toward getting it finished. I have put a lot of personal time and money into the project (a couple hundred thousand $) but it is still only about half finished. It is a very ambitious project. I finally had to go back to work to feed my family, but I still work on it in my spare time. I am determined to finish it, but it will be years later than it could have been with some funding.

  11. Re:Good job by alvinrod · · Score: 1

    So what? It doesn't need to.

    Linux is a free market of ideas and devotion. Projects that are interesting or useful tend to attract developers who are willing to contribute to the project. Those that are unnecessary or niche tend to languish or serve an obscure base of users. Regardless of where along that spectrum any project falls, we're all collectively richer through no effort of our own and at no cost beyond learning to use the software.

    If the ability to create your own solution or choose from among many doesn't interest you, you don't have to use it. Air hockey is unlikely to replace football, but that doesn't mean you still can't enjoy it if it's to your tastes.

  12. Re: Another one? by phantomfive · · Score: 1

    As opposed to working on fixing one of the existing filesystems?

    Yes. If everyone worked on the same thing, we would never see progress in the world. There are already people working on the existing file systems.

    If you want to look at it another way, it's like we have a genetic algorithm, randomly designing file systems, and only the best survive. If this keeps up, eventually the file systems on Linux will be very, very good.

    --
    "First they came for the slanderers and i said nothing."
  13. Re:Good job by rubycodez · · Score: 2

    Strange, on Earth the internet is not powered by windows servers but rather Linux and BSD ones, nor are smart phones running windows but BSD and Linux. What planet do you live on? The planet of the twats?

  14. Re:Good job by rubycodez · · Score: 1

    who gives a shit? only twats like you apparently

  15. Re:Another one? by asimons04 · · Score: 1

    Exactly! I absolutely love btrfs, but it is still more or less experimental and under constant develoment. Why can't Overstreet and his team just work with the btrfs team since they're looking at basically the same feature set. I love Linux and all, but geez, we don't need to reinvent the wheel every few years.

  16. Re: Another one? by Bengie · · Score: 1

    A generic algorithm that takes 10 years between each iteration. btrfs has some cool things, but has some horrible things that seem cool to a dev because of all the complex setups you can do, but sounds like a nightmare to a sysadmin because of all the complex setups it can do. It also forgoes some very important features to gain these "nifty" features.

    ZFS is really great, but not perfect. How about someone takes the idea of ZFS, but with no legacy dependencies to hold them down, and implement it in a way that makes up for its shortcomings, like no pointer re-write? One idea that I like about btrfs is configurable raid levels per volume.

  17. Re: Another one? by Desler · · Score: 1

    Why? Are filesystems important for NBA team owners?

  18. No no no no no by JustAnotherOldGuy · · Score: 1

    "It probably won't eat your data — but no promises."

    Well, that's a ringing endorsement if I ever heard one. Thanks but no thanks.

    --
    Just cruising through this digital world at 33 1/3 rpm...
  19. Hmmmm by eyegone · · Score: 4, Insightful

    I guess writing a new filesystem is easier than fixing the existing bugs in bcache itself.

    --
    "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
  20. Filesystems with Smaller USB Flash Cache? by billstewart · · Score: 1

    Sure, I can understand why, if you're building a ZFS server with tens of terabytes of disk and tens of GB of RAM, you can dedicate an SSD to accelerating it. But more commonly, I'm using a laptop or older desktop that doesn't really have enough horsepower to do that, and may not have room for both an SSD and a spinning disk, and I'd like to just throw a random USB stick on their to use for caching. Windows had something like that for a while (never really helped much, and now that my work laptop has an SSD it doesn't use it at all), but is there some way to accelerate my boring desk-side lab box at work by plugging in a 4-8GB flash stick? Or to accelerate the wimpy server we're using for OpenStack?

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  21. When are we getting a taggable filesystem? by recrudescence · · Score: 1

    Seriously, no 'file manager' solution I've seen so far works adequately, and in a way that preserves such tags across devices / disks / etc. What do other slashdotters do for tagging purposes?

    1. Re:When are we getting a taggable filesystem? by DidgetMaster · · Score: 1

      I am working on it now but without funding it is going much slower than I had hoped. About half finished, but works great so far. See the video at http://youtu.be/2uUvGMUyFhY

    2. Re:When are we getting a taggable filesystem? by DidgetMaster · · Score: 1

      Although the UI in the demo is running on Windows, it is built with Qt so it is easily ported to other platforms. I plan on getting it running on Linux and OSX as well. I know that need to get some better video of the demo as well. I have just been concentrating on getting features working a lot more than on trying to promote it.

  22. Re:zlib? Really? by Bengie · · Score: 1

    SKEIN 256/512 was a SHA3 finalist and is only 1/2 the speed of SSE4 CRC32C, and that is on a CORE2 DUO with out modern SIMD. For half the speed on any 64bit machine you gain many more bits and cryptographic strength.

  23. Re: Another one? by Bengie · · Score: 1

    Yeah, file systems are not created often, so if you're going to create one, you best make sure it's at least better on paper than what is out there. We don't need speed, we need scaling. Even ZFS has issues with large amounts of memory and dedup is horrible on large pools. HAMMER2 sounds awesome, but it does have a lot of crazy features that make it more complex which increases the chance of bugs, not coming to fruition or not getting ported to all Open source OSes. I don't need master-master distribution.

  24. Ack! Typo! by billstewart · · Score: 1

    s/their/there/

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks