[9front] gefs: call for testing

[9front] gefs: call for testing

[ori]

In the last few weeks, GEFS has moved from "will definitely eat
your data" to "will likely eat your data". So, it's about time
to get more people trying it out.

be0ba has written a script to set up a gefs root, so it's easy
to create a test install with a gefs root:

	https://tcp80.org/grobe0ba/gefsroot/HEAD/info.html

For everyone that's already been testing and sending me reports,
thanks!

Re: [9front] gefs: call for testing

[ori]

First off -- all, thanks for testing out the FS, and all the
feedback/bug reports I've gotten.

I've just pushed a revision of the on disk format; the last
rev was fine, but I figued I had a chance now to sand out a
few rough spots before too many people started using this.
I hope (but don't promise yet) that future updates should be
compatible.

Second, I'm aware of old snapshots sometimes getting fucked;
finding and fixing that is my next thing. Hope to have some
updates on that front soon.

Quoth ori@eigenstate.org:
> In the last few weeks, GEFS has moved from "will definitely eat
> your data" to "will likely eat your data". So, it's about time
> to get more people trying it out.
> 
> be0ba has written a script to set up a gefs root, so it's easy
> to create a test install with a gefs root:
> 
> 	https://tcp80.org/grobe0ba/gefsroot/HEAD/info.html
> 
> For everyone that's already been testing and sending me reports,
> thanks!
> 

Re: [9front] gefs: call for testing

[ori]

Quoth ori@eigenstate.org:
> 
> Second, I'm aware of old snapshots sometimes getting fucked;
> finding and fixing that is my next thing. Hope to have some
> updates on that front soon.

Found the rather embarrassing bug that was causing old snapshots
to get corrupted; we were freeing the tree when the refcount
decreased, which is not necessarily when it went to 0.

Re: [9front] gefs: call for testing

[ori]

Quoth ori@eigenstate.org:
> Quoth ori@eigenstate.org:
> > 
> > Second, I'm aware of old snapshots sometimes getting fucked;
> > finding and fixing that is my next thing. Hope to have some
> > updates on that front soon.
> 
> Found the rather embarrassing bug that was causing old snapshots
> to get corrupted; we were freeing the tree when the refcount
> decreased, which is not necessarily when it went to 0.
> 

Had it grind on building isos in a loop for about a day and
a half, with no problems. At this point, the TODO list is
down to:

commit blockers:
	- atomics for all archs
	- docs

important, after committing:
	- repair tools

future features:
	- non-adm controlled snapshots
	- reclaiming data from deleted files is very delayed
	- performance optimization:
		- bulk block frees
		- root block faster upsert
	- small file optimizations
		- inline data

The future features can all be added without breaking disk
format -- even tweaking block sizes should be doable, as
long as blocks stay below 64k.