[9fans] df for fossil?

[9fans] df for fossil?

[Fco.J.Ballesteros]

is there an easy way to obtain disk usage stats for fossil?

thanks

Re: [9fans] df for fossil?

[Russ Cox]

> is there an easy way to obtain disk usage stats for fossil?

not without writing some code.

Re: [9fans] df for fossil?

[Russ Cox]

i lied.  you can run flchk -f.
it will take longer than necessary,
but eventually print disk usage stats.

Re: [9fans] df for fossil?

[Fco.J.Ballesteros]

Yep. I already saw flck, but I was wondering about
some field in some hdr about the # of blocks. I found no
such thing.

In any case, flck is enough for me now; I'm using fossil
as our file server for daily work, don't know how it behaves
when the partition gets full and was a bit scared about that.

thanks a lot

Re: [9fans] df for fossil?

[Russ Cox]

When a partition gets full you get lots of disk full
errors, as you might expect.  Unlike in a normal file system, you
might not even be able to walk around and read the file system,
since walking the file system potentially means allocating
blocks to update atimes.

It recovers gracefully though.  When sources filled
a few weeks ago, I just connected to the console and
tossed some old snapshots with epoch -y.

If you fill the write buffer and have no snapshots to
discard, then all your blocks must be mutable, so 
you should be able to walk around in the file system
and remove files.  We should probably keep a few
blocks reserved for running an emergency flush-to-Venti 
`snap -a'.  (There's little hope for recording the snapshot
in the /archive tree, but if we kept one block around then
we could use it to clone the root and start an archive of
the resulting anonymous snapshot.)

Russ

Re: [9fans] df for fossil?

[Fco.J.Ballesteros]

Keeping blocks reserved looks much better for me,
since (for example, in my case) fossil can be your
root file system, and you'll need to read it just to boot
enough to recover it.

By now I think I'll just make an emergency boot disk with
that runs just the fossil console, to let me type without
using the fossil.

thanks a lot.

PS: /main/snapshot/ is great.

Re: [9fans] df for fossil?

[Russ Cox]

> Keeping blocks reserved looks much better for me,
> since (for example, in my case) fossil can be your
> root file system, and you'll need to read it just to boot
> enough to recover it.

This doesn't make sense to me.

The only time you need blocks in reserve is when:

	- you are out of disk space
	- you have no snapshots to discard
	- you do not want to remove any data from the write buffer
	- you want to do an anonymous archival snapshot

If you mount the file system read-only you can *always*
read the whole thing.

Reserving two blocks on the disk for anonymous
archival snapshot roots would be sufficient to solve the problem:
you can be using at most one for the current file system root,
so at least one must be free (or at least, will be free once the
archiver finishes archiving that snapshot).

> By now I think I'll just make an emergency boot disk with
> that runs just the fossil console, to let me type without
> using the fossil.

I would just boot the bleeding edge sources CD.
Then you'd have a whole system at your disposal.

Russ

Re: [9fans] df for fossil?

[Fco.J.Ballesteros]

I'm confussed.
If you said that the fossil in sources is already reserving those
two blocks for that purpose, then I didn't understand it right and I'll
delete the rescue kernel I just made.

If you said instead that fossil should reserve those two blocks but it's
not doing so yet, then I think that means `as of today there're some times
when it would allow you to run snap -a'. 

But in any case, I'm running right now with the sources as of yesterday night (madrid
time), and a pull this morning got nothing new for fossil.

Maybe I just need a coffee :-)

Re: [9fans] df for fossil?

[Russ Cox]

There are two separate issues here.

#1:
You don't ever need a `rescue' kernel.  It's unlikely that a kernel
with any particular preordained set of tools would be that helpful
without being enormous.  A bootable CD with the full system
(which already exists) would be a lot more helpful.

#2:
Fossil does *not* reserve two blocks for emergency archival
snapshots.  As of today there are times when you would get stuck
and not be able to do anything.  However, that *only* happens when:

	- your disk is full
	- *and* you have no snapshots to discard or refuse to discard them
	- *and* you refuse to delete one of your active files to make space

Notice that being ``stuck'' requires stubbornness on your part
in addition to Fossil being out of disk space.

In that situation, right now, as of today, the right thing to do is:

	- stop being stubborn
	- pick an active file
	- copy it somewhere else
	- remove it
	- run snap -a to archive blocks to Venti,
		hopefully freeing most of the disk
	- copy the file back

You can *always* do that.

Russ

Re: [9fans] df for fossil?

[Fco.J.Ballesteros]

Ok. Now I understand. Sorry I didnt catch on
the first time.

I don't need to worry then. I have snapshots around that I can just
delete if that case ever happens. Don't know why but I understood that
I needed the space even to discard a snapshot.

Thanks a lot.