orib.dev: Gefs – Future Work
Gefs was recently committed to 9front. Because it hasn’t had many miles put on it yet, I still consider it very experimental.
It is available as a hidden option in the installer. You can get a GEFS based system by manually typing gefs at the prompt where it asks you to select between cwfs64x and hjfs.
While gefs is in tree, it’s far from done. This is an incomplete list of future work that I would like to complete:
Repair tools; right now, we can check for corruption, but more would be welcome. there’s also nothing to fix corruption if it’s detected. Storing small files inline; there’s no need to create a new block if the file is smaller than the maximum size of a value in the Bε tree. Mer…
orib.dev: Gefs – Future Work
Gefs was recently committed to 9front. Because it hasn’t had many miles put on it yet, I still consider it very experimental.
It is available as a hidden option in the installer. You can get a GEFS based system by manually typing gefs at the prompt where it asks you to select between cwfs64x and hjfs.
While gefs is in tree, it’s far from done. This is an incomplete list of future work that I would like to complete:
Repair tools; right now, we can check for corruption, but more would be welcome. there’s also nothing to fix corruption if it’s detected. Storing small files inline; there’s no need to create a new block if the file is smaller than the maximum size of a value in the Bε tree. Merging/annihilating messages early; right now, all messages flush all the way down to the leaf before being applied, but they could be merged early; eg, a delete could eliminate an insert, or a chain of mtime changes could be merged into one. Modifying the root block buffer in-place; right now, the root block is copied for every upsertion. With some care, an upsert can modify the in-memory copy of the root block, which only needs to be serialized and flushed on sync or when it is full. Custom snapshot timing; right now, snaps are either taken automatically on a hard-coded schedule, or not taken at all. Microoptimization; right now, performance is ok, but could be faster; measure and optimize. Doing more eager space reclaim; getting back space from deleted files is delayed, and we could do some work in the sweeper to reclaim the space early. Raid and Autorepair; it would be useful to have the filesystem able to support raid. It would also be and to use the corruption detection it has to build in to repair corrupt reads. The split between devfs and the file system in this situation isn’t clear.
All of these seem like they should be easy to implement without any breaks to compatibility. The locations for feature flags are all in place.
I plan to hack on these as time permits, but at a fairly low priority. Patches are welcome.