9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] df for fossil?
Date: Tue, 14 Jan 2003 10:48:51 -0500	[thread overview]
Message-ID: <27e4ae2fbf975f23cfde59e10f1f8d67@plan9.bell-labs.com> (raw)
In-Reply-To: <a695b3f0cfbfeba91974e8fcaf960b3c@plan9.escet.urjc.es>

> 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



  reply	other threads:[~2003-01-14 15:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-14  9:12 Fco.J.Ballesteros
2003-01-14 12:52 ` Russ Cox
2003-01-14 13:23   ` Russ Cox
2003-01-14 14:57   ` Fco.J.Ballesteros
2003-01-14 15:06     ` Russ Cox
2003-01-14 15:34       ` Fco.J.Ballesteros
2003-01-14 15:48         ` Russ Cox [this message]
2003-01-14 15:57           ` Fco.J.Ballesteros
2003-01-14 16:10             ` Russ Cox
2003-01-14 16:16               ` Fco.J.Ballesteros

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27e4ae2fbf975f23cfde59e10f1f8d67@plan9.bell-labs.com \
    --to=rsc@plan9.bell-labs.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).