[lkml]   [2019]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: bcachefs status update (it's done cooking; let's get this sucker merged)

is there a chance to get this in Kernel 5.3?
And thanks for this fs!

On Monday, June 10, 2019 9:14:08 PM CEST Kent Overstreet wrote:
> Last status update:
> Current status - I'm pretty much running out of things to polish and excuses to
> keep tinkering. The core featureset is _done_ and the list of known outstanding
> bugs is getting to be short and unexciting. The next big things on my todo list
> are finishing erasure coding and reflink, but there's no reason for merging to
> wait on those.
> So. Here's my bcachefs-for-review branch - this has the minimal set of patches
> outside of fs/bcachefs/. My master branch has some performance optimizations for
> the core buffered IO paths, but those are fairly tricky and invasive so I want
> to hold off on those for now - this branch is intended to be more or less
> suitable for merging as is.
> The list of non bcachefs patches is:
> closures: fix a race on wakeup from closure_sync
> closures: closure_wait_event()
> bcache: move closures to lib/
> bcache: optimize continue_at_nobarrier()
> block: Add some exports for bcachefs
> Propagate gfp_t when allocating pte entries from __vmalloc
> fs: factor out d_mark_tmpfile()
> fs: insert_inode_locked2()
> mm: export find_get_pages()
> mm: pagecache add lock
> locking: SIX locks (shared/intent/exclusive)
> Compiler Attributes: add __flatten
> Most of the patches are pretty small, of the ones that aren't:
> - SIX locks have already been discussed, and seem to be pretty uncontroversial.
> - pagecache add lock: it's kind of ugly, but necessary to rigorously prevent
> page cache inconsistencies with dio and other operations, in particular
> racing vs. page faults - honestly, it's criminal that we still don't have a
> mechanism in the kernel to address this, other filesystems are susceptible to
> these kinds of bugs too.
> My patch is intentionally ugly in the hopes that someone else will come up
> with a magical elegant solution, but in the meantime it's an "it's ugly but
> it works" sort of thing, and I suspect in real world scenarios it's going to
> beat any kind of range locking performance wise, which is the only
> alternative I've heard discussed.
> - Propaget gfp_t from __vmalloc() - bcachefs needs __vmalloc() to respect
> GFP_NOFS, that's all that is.
> - and, moving closures out of drivers/md/bcache to lib/.
> The rest of the tree is 62k lines of code in fs/bcachefs. So, I obviously won't
> be mailing out all of that as patches, but if any code reviewers have
> suggestions on what would make that go easier go ahead and speak up. The last
> time I was mailing things out for review the main thing that came up was ioctls,
> but the ioctl interface hasn't really changed since then. I'm pretty confident
> in the on disk format stuff, which was the other thing that was mentioned.
> ----------
> This has been a monumental effort over a lot of years, and I'm _really_ happy
> with how it's turned out. I'm excited to finally unleash this upon the world.

 \ /
  Last update: 2019-07-03 08:01    [W:0.168 / U:3.952 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site