Re: bcachefs: can bcachefs export block devices?

On Wed, May 25, 2016 at 02:47:29PM -0700, Eric Wheeler wrote:

quoted

Does bcachefs's implementation reuse and update the existing 
bcache code such that the block device driver inherits the bcachefs 
improvements?  I understand the cache superblock changed, maybe the cached 
dev super too.

Yes, all of the existing functionality is still there (though some of it's
broken at the moment because I haven't been running those tests; if you're
interested in using bcache-dev for the old style caching (there are performance
and robustness improvements) it wouldn't take me long to get it working again).

I can test that once its working.  Would it use the same bcachefs tools 
for formatting superblocks?

Relatedly, can you point out the best place to abstract cachemeta-v1 vs. 
cachemeta-v2 for simultaneous use?  Could it be just a bunch of function 
pointers in the cachedev struct and assignment during initialization for 
v1/v2?  Have the call arguments changed? What functions would need 
abstractions (the smallest v1/v2 intersection)?

quoted

Can bcachefs provide /dev/bcacheN devices without loop.ko?  

If so, are these simply filesystem objects (files)?

The way it works is the first 4096 inode numbers are owned by the block device
interface - inodes in that range are for either cached devices or thin
provisioned volumes. The filesystem code owns inode numbers >= 4096.

So while blockdev volumes/cached data do have inodes, they're not reachable via
the filesystem because there will never be dirents that point to them (also,
they use a different inode type with extra fields for the UUID/label).

Thats a neat implementation.  Would creating a dirent for such an inode 
expose the block device with the same size and content (and ordering) if 
if the inode were compatable?  Would the blockdev be block-size aligned 
versus the file or might the file have an alignment requirement?

I'm particularly excited about this as a precursor to snapshot support, 
especially if udev could help produce something like this:

  /dev/disk/by-path/bcache-mydiskfile -> /dev/bcacheN
  /dev/disk/by-path/bcache-mydisksnap -> /dev/bcacheN+1


--
Eric Wheeler

On Wed, 25 May 2016, Kent Overstreet wrote:

However - there isn't anything preventing us from writing a bit of new code and
hooking it up to an ioctl or sysfs interface to say "look up this path and
create a block device for that file". The only remotely tricky bit would be
pagecache cache coherency, but I think you get the new block device to just use
the same address_space (pagecache cache for an inode) as the filesystem inode.

So, probably doable in ~100 lines of code or so.
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html