Announcement

Collapse
No announcement yet.

Bcachefs Completes Core Feature Work, Could Merge Soon If Review Goes Well

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

  • david@newhamlet.com
    replied
    Originally posted by Britoid View Post

    Wasn't the functionality of bcache merged in with bcachefs?
    https://bcachefs.org/ : “Caching” - with SSD?

    Leave a comment:


  • hotaru
    replied
    have they fixed this bug yet?

    https://www.phoronix.com/scan.php?pa...uption-Linux-5
    https://www.phoronix.com/scan.php?pa...Corruption-Hit

    Leave a comment:


  • geearf
    replied
    Originally posted by Britoid View Post

    Wasn't the functionality of bcache merged in with bcachefs?
    Well bcache was the base of bcachefs so yes.
    It might be feasible later to use bcachefs just for the features of bcache today, not sure, but the currents issues with bcache in master are completely not looked at by Kent anymore, and in one current issue a maintainer admitted not knowing enough to say much... This kind of stuff worries me for an fs....

    Leave a comment:


  • ermo
    replied
    I think the review thread on LKML is interesting mainly because (AIUI) Dave Chinner is telling Linus that a specific piece of (supposedly generic) kernel code for managing locks is broken enough that it's caused the xfs devs so much pain that Dave refuses to rely on it, while Linus wants it to be stress-tested and stabilised.

    One could easily be led to suspect that perhaps the Linux kernel is -- to paraphrase the inimitable Eddie Izzard -- being held together by string, duct-tape and a note from Linus' mother.
    Last edited by ermo; 06-11-2019, 07:43 PM.

    Leave a comment:


  • jpg44
    replied
    Originally posted by pal666 View Post
    basically, subj is at stage where btrfs was in 2008
    why another pile of bugs is so exciting?
    and if not then what?
    redhat could hire someone to work on btrfs. even some dozens of people instead of one. how does it work for redhat?

    so some idiot over internet is excited by thoughts of someone else pouring hundred man-years onto chasing already existing filesystem?
    There have been issues with btrfs. Overstreet explains this in his discussions about why bcachefs is worthwhile. btrfs code base is over-complicated and the filesystem is not necessarily easy to penetrate or maintain for outsiders. The filesystem is partiy a culture around its codebase and developers who are able to penetrate and understand its code so they can maintain it. That is, if a code base is extremely overly complex, it can be cheaper to re-implement than it is to try to fix it.

    Overstreet also is confident he can outdo btrfs on performance.

    bcachefs codebase has a different design characteristic that is easier for many developers to work on.

    The filesystem is based on existing bcache code in the kernel so the additional code to bring it to a full featured filesystem was not as great as a from scratch implementation.

    Leave a comment:


  • mmstick
    replied
    Originally posted by bitman View Post

    Now that would perform real fast. Not.
    Honestly, I doubt there's any measurable difference. Placing drivers in the kernel doesn't magically make them faster, either.

    Leave a comment:


  • pal666
    replied
    basically, subj is at stage where btrfs was in 2008
    Originally posted by jpg44 View Post
    This is very exciting and Linux can use an alternative to ZFS and Btrfs.
    why another pile of bugs is so exciting?
    Originally posted by jpg44 View Post
    Especially if it turns out to be faster,
    and if not then what?
    Originally posted by jpg44 View Post
    it could become a preferred filesystem. RedHat or Canonical really should just hire him
    redhat could hire someone to work on btrfs. even some dozens of people instead of one. how does it work for redhat?
    Originally posted by jpg44 View Post
    to continue to improve bcachefs including making sure that there is a working RAID56, that writable snapshots work well, that it can support multiple physical volumes being loaded into a volume group and having a feature like Btrfs's subvolumes.
    so some idiot over internet is excited by thoughts of someone else pouring hundred man-years onto chasing already existing filesystem?

    Leave a comment:


  • pal666
    replied
    Originally posted by mmstick View Post
    Honestly, I'd rather that we move all file system drivers to user space.
    use hurd then

    Leave a comment:


  • jpg44
    replied
    This is very exciting and Linux can use an alternative to ZFS and Btrfs. Especially if it turns out to be faster, it could become a preferred filesystem. RedHat or Canonical really should just hire him to continue to improve bcachefs including making sure that there is a working RAID56, that writable snapshots work well, that it can support multiple physical volumes being loaded into a volume group and having a feature like Btrfs's subvolumes.

    Leave a comment:


  • Volta
    replied
    Originally posted by DoMiNeLa10 View Post

    There would be no discussion about this if we would be using microkernels.
    No doubt. Everything would be slow in such case.

    Leave a comment:

Working...
X