3 ms·
Oh wow... That's actually really fast progress all things considered. Well done! I really hope all the... umm... misunderstandings get worked out because you're
by biorach 2y ago
Oh wow... That's actually really fast progress all things considered. Well done! I really hope all the... umm... misunderstandings get worked out because you're doing great work.
- koverstreet 2y agoIt's all stuff that's been in the pipeline for a long time. (And we'll see when online fsck and erasure coding actually land, I keep getting distracted by more immediate issues). Really, the bigger news right now is probably all the self healing work that's been going on. We're able to repair all kinds of damage without an explicit fsck now, without any user intervention: some things online, other things will cause us to go emergency read only and be repaired on the next mount (e.g. toasted btree nodes).
- qhwudbebd 2y agoOne of the choices you've made that I really like is sharing the kernel and userspace filesystem code so directly in the form of libbcachefs. I get the impression this means the kernel can do practically everything userspace can, and vice versa. (I think the only exception is initialising devices by writing a superblock, although the kernel can take over the initialisation of the rest of the filesystem from that point onwards? And maybe turning passphrases into keys for encrypted-fs support which does an scrypt thing?) As well as giving you really powerful userspace tools for manipulating filesystems, this also suggests that a stripped down busybox module for bcachefs could consist of superblock writing and pretty much nothing else? Maybe a few ioctls to trigger various operations. "Just leave it all to the kernel."