Conversation

I skimmed through that and I love how they have some of the basic concepts from my vaporware kernel (fs being provided by a userspace process, only visible to procs attached to it) but then botched a lot to make that happen s.t. mmap is read-only. 🤦🤦🤦
3
...and demand paging doesn't exist. 🤦 ...and you have to use mmap rather than read for performance. 🤦 This all comes out naturally right if the only underlying operation is mmap-like and read/write are always kernel-mediated memcpys.
2
1
Replying to and
I think the reason that it's not implemented is simply that only BlobFS implements demand paging so far and BlobFS is write-once content addressable. I don't think there's any design issue or blocker for it. They just haven't gotten around to implementing it for a normal fs yet.
1
2
Replying to and
I think they're working on implementing F2FS but it's a lot of work especially for it to be fully compatible. It doesn't help that Linux F2FS is in very active development and regularly upgrading the on-disk format. You can't downgrade the major kernel version with F2FS yet...
1
1
F2FS has really great performance and reliability but it's only currently a serious choice where you're heavily testing major kernel upgrades in advance and are completely sure you won't need to downgrade. I'm sure that hurts the development-focused Fuchsia use case right now.
1
1
I still use ext4 on my workstations in case I ever need to downgrade the kernel, especially since I use a rolling release distribution. OS development with that constraint is probably not fun. I broke that rule before and had to reformat since F2FS became unable to reuse space.
1