Announcement

Collapse
No announcement yet.

Bcachefs Might Be Ready For Upstreaming In Linux This Year

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

  • LinAdmin
    replied
    Update April 2023:
    Raid-1 seems to be ready and I will soon test it...

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by alcalde View Post

    Thank you! Bcache was basically abandoned for bcachefs and bcache ended up eating my hard drive data. :-( Fortunately LVMcache works, but still....

    We really didn't need yet another file system anyway. Any ideas for improvements could have been submitted to btrfs.
    to make it an even more of a clusterfuck than it already is?

    Leave a comment:


  • alcalde
    replied
    Originally posted by Jannik2099 View Post
    There are still a bunch of severe bugs in bcache that haven't been fixed for years, anyone jumping on bcachefs straight away is just asking to repeat the early btrfs experience.

    It's a single dev, working on a filesystem with about as many features as ZFS - calm your expectations
    Thank you! Bcache was basically abandoned for bcachefs and bcache ended up eating my hard drive data. :-( Fortunately LVMcache works, but still....

    We really didn't need yet another file system anyway. Any ideas for improvements could have been submitted to btrfs.




    Leave a comment:


  • mdedetrich
    replied
    Originally posted by pal666 View Post
    lol. in 2008 btrfs had on-disk format finalized and was in a state "just before mainlining"(in next year it was in a state "mainlined"). bcachefs now is buggy mess according to its author
    "A big allocator rewrite is about to land, and after that will be backpointers - to fix copygc scanning. Things are in flux lately with all the allocator work, but I'm hoping once that settles down and I've worked through the backlog of bug reports and performance regressions"
    it's really stupid to compare in calendar years. 7 years of part-time marketing is much less than one year of fulltime work of several people
    You should work at a PR agency, you do a wonderful job of spinning something to the complete opposite of whats actually happening.

    All I am seeing is that btrfs rushed out its on-disk format in the early years when it was barely in alpha/beta where as Kent is actually taking his time to make sure things are correct to actually avoid all of the issues that have plagued BTRF's and he is being honest about it.

    That and people clearly have double standards when it comes to bcachefs i.e. people complaining that bcachefs is unready because it doesn't have scrubbing when as literally stated, btrfs was mainlained without scrubbing which was only added 3 years later.

    If filesystems were corporations and phoronix members had shares in them this would be somewhat believable, all I am seeing here is just blind fandboyism which is ironic for an ecosystem/kernel that prides itself on "technical excellence".

    Like seriously, who gives a flying f**k if bcachefs ends up beating btrfs because its technically superior, or vice versa if it doesn't end up being as good or only marginally better. Let the technically best one win and stop throwing out hypocritical/double standard/FUD bs at someone who is just trying to make a better filesystem.

    Grow up.

    Leave a comment:


  • pal666
    replied
    Originally posted by pkese View Post

    2008 Btrfs had the first internal prototype code at Oracle (Chris Mason joined Oracle in late 2007 to work on btrfs).
    lol. in 2008 btrfs had on-disk format finalized and was in a state "just before mainlining"(in next year it was in a state "mainlined"). bcachefs now is buggy mess according to its author
    "A big allocator rewrite is about to land, and after that will be backpointers - to fix copygc scanning. Things are in flux lately with all the allocator work, but I'm hoping once that settles down and I've worked through the backlog of bug reports and performance regressions"
    Originally posted by pkese View Post
    2015 Bcachefs was announced (after a few years' unfunded development)
    it's really stupid to compare in calendar years. 7 years of part-time marketing is much less than one year of fulltime work of several people
    Last edited by pal666; 18 February 2022, 08:19 PM.

    Leave a comment:


  • kreijack
    replied
    Originally posted by Draget View Post

    Even right now on my ECC-backed, enterprise-disk homeserver I have two old btrfs disks that seemed have a broken free disk space cache, not fixed by a scrub.
    Scrub simply compare the data against its checksum and rebuild the data if another copy is available.
    If you have the space cache broken, you can rebuild it using the mount option "clear_cache".
    See https://btrfs.readthedocs.io/en/latest/btrfs-man5.html

    Leave a comment:


  • kreijack
    replied
    Originally posted by pkese View Post

    2008 Btrfs had the first internal prototype code at Oracle (Chris Mason joined Oracle in late 2007 to work on btrfs).
    2009 (+1) got mainlined into Linux kernel.
    2011 (+3) got scrubbing and defragmenting features
    I found in the source that the de-fragmentation was born around 2008; you are right that scrubbing was added late in 2011 but raid1 rebuild was working in 2010 [1]


    Originally posted by pkese View Post

    2012 (+4) SUSE and Oracle Linux changed it's status from "experimental" to "production" or "supported".
    2015 (+7) it was adopted as the default filesystem for SUSE Enterprise Linux Server.

    2015 Bcachefs was announced (after a few years' unfunded development)
    2022 (+7) Bachefs may become mainlined as Experimental this year. According to a comment above, no scrubbing feature had been implemented yet.


    [1] http://ptspts.blogspot.com/2010/06/d...disk-data.html

    Leave a comment:


  • LinAdmin
    replied
    Originally posted by lyamc View Post

    True, but I also understand why: easier to add after. There's also been ongoing discussions on how to best implement scrubbing: https://lwn.net/Articles/754504/
    Many thanks for your interesting link.
    However, I am still convinced that the best way to proceed would be:

    a) Determine the on disk data structures for all planned features.
    b) Realize the most basic functionality of writing, reading and changing files.
    c) Implement data repair in case that reading shows crc-errors.
    d) Implement scrubbing.

    At this point the code would be ready for mainlining.
    This will bring the test coverage that can not be obtained by own testing.

    e) Implement remaining functionality like snapshots.

    Leave a comment:


  • lyamc
    replied
    Originally posted by LinAdmin View Post

    Not only scrubbing is missing, but also automatic repair in case any reading detects a mismatch of crc.
    True, but I also understand why: easier to add after. There's also been ongoing discussions on how to best implement scrubbing: https://lwn.net/Articles/754504/

    Dave Chinner wondered if there was a way to have a single scrubbing command that handled any kind of filesystem, so that users do not have to remember how to do it for each type. No one seemed opposed to the idea but getting there may take some time.

    Leave a comment:


  • anarki2
    replied
    Originally posted by mdedetrich View Post
    Really looking forward to seeing the release, especially fond of Kent's attitude in developing bcachefs (i.e. get the core design principles right before releasing it).
    He doesn't really have other choices as it's been rejected before lol.

    Leave a comment:

Working...
X