Re: [squid-users] Re: Squid 1.2 formats and other Q's.

On Tue, 15 Sep 1998, Chris Tilbury wrote:

> Date: Tue, 15 Sep 1998 09:14:58 +0100
> From: Chris Tilbury <cudch@csv.warwick.ac.uk>
> To: Henrik Nordstrom <hno@hem.passagen.se>
> Cc: squid-users@ircache.net
> Subject: Re: [squid-users] Re: Squid 1.2 formats and other Q's.
> Resent-Date: Tue, 15 Sep 1998 01:17:22 -0700 (PDT)
> Resent-From: squid-users@ircache.net
>
> On Tue, Sep 15, 1998 at 08:24:49AM +0200, Henrik Nordstrom wrote:
>
> > Chris Tilbury wrote:
> >
> > > This is, of course, something that isn't addressed by either a
> > > transaction log or a stripe. You'd need to make a logged, mirrored,
> > > stripe. This is going to be quite expensive in terms of hardware.
> >
> > I don't agree fully here. Cache filesystems are different from normal
> > filesystem. If one disk fails it does not matter much loosing the
> > contents of that disk, as long as the contents of the other disks are
> > not affected. Especially if the gain from not using mirroring is the
> > double number of available disks spindles (and space) for the same
> > price.
>
> I don't think we're actually disagreeing here. There is only one way to get
> resilience into a RAID0 striped filesystem, and that is to mirror it (RAID
> 10, 1+0, call it what you will). If you lose one component of a stripe, you
> lose the filesystem. There's no way around this, it's a fact :-).
>
> You're quite right in that if you are using each disk as a separate entity,
> then if you lose one then you can still preserve the remainder of the cache,
> though. There would certainly be no point to mirroring individual disks in
> this scenario.
>
> You still don't address write performance doing this, though. You'll still
> have synchronous writes taking place (metadata updates, etc), which will
> cause a performance degradation. Using a transaction log (or NVRAM if you
> are very rich) _will_ help this. Sure, you can often turn many of these off
> by disabling synchronous writes of metadata, but that can have adverse side
> effects too.
>
> (There's nothing to stop you using a transaction log on a filesystem, on a
> single disk by the way, at least not with DiskSuite. It could be a shared
> log, split between many different filesystems on different disks, too).
>
> > The same applies to if a machine crashes & reboots. It does not matter
> > if you loose some of the cached files.
>
> True, but it does matter if the machine can't properly restart because it
> cannot clean the cache filesystem(s). This is the risk you increase vastly
> if you disable synchronous metadata updates to get the performance increase.
> It could mean the difference between the cache coming back to life of its
> own accord, or sitting at a single user login prompt waiting for someone to
> come and fsck it. I know which I'd rather happened.
>

I guess the other issue is how long is it going to take to fsck large
dirty filesystems. It amounts to downtime.

But, regardless, a user is generally not required if you modify your
run level start script to force fsck with -y.

If i ran squid with async I/O, I would most definately use fsck -y on boot.

Regards
Peter Marelas
Received on Tue Sep 15 1998 - 07:41:29 MDT