On Fri, Jun 25, 2021 at 02:12:07PM +0000, adr via 9fans wrote:
> On Fri, Jun 25, 2021 at 01:41:30PM +0100, Richard Miller wrote:
> > > it just becomes difficult
> > > to do anything when no fossil blocks can be allocated
> >
> > Thinking a bit further about this: intuitively one might expect to be
> > able to reboot using a local file system which is completely full, and
> > use du and ls to find big files and rm to delete them, without the need
> > to allocate new blocks. Something in the way fossil works, makes this
> > impossible at present. I wonder how much work it would be to investigate
> > and fix?
>
> I haven't studied how fossil works, so excuse this light chat.
> Couldn't fossil have reserved blocks so when it starts and it's
> full it can add those block and present the user to a recovery
> session? Just a console session printing the last file modified?

I don't think I will tell anybody a scoop, but it is what is present in
traditional Unix filesystems where there is a percent of the storage
preserved... but for root, user under which you are not supposed to
log to the system in normal operation. This is probably the problem:
since there is no privileged user, for "whom" to preserve/reserve these
blocks?

I imagine the alternative would be, if fossil reports full, that memory
filesystems should be mounted on top of the system mandatory writable
dirs so that the system will not block but normal booting will not
be done but the program launched will be one requiring user to make
room, crucial infos written in memory filesystems being copied back
to fossil when done. But it is easier to implement when booting/rebooting,
but more problematic if the system is running. Except perhaps that
there will always be a memory filesystem mounted with rescue
programs/scripts that the user can precisely use when the system
is out of disk space, utilities that write nothing to disk (but just in
their memory realm), in order to not paint oneself in a corner.