Subject: Re: LFS frailty vs. datestamping [Was Re: /dev/clock pseudodevice]
To: gabriel rosenkoetter <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 07/30/2001 17:25:37
On Mon, 30 Jul 2001, gabriel rosenkoetter wrote:
> On Mon, Jul 30, 2001 at 01:05:15PM -0700, Andrew Gillham wrote:
> > Yes, I was abusing the poor partition. :) But to Bill's point you
> > can easily run out of free/clean segments if you have something that
> > is using segments at a high rate. (e.g. database / high volume MTA)
The main point was that different FSs are good at different things. Saying
one is better than another OVERALL is a difficult-to-support arguement.
> Sure. Theoretically LFS should be able to be graceful about that
> too, up to a point, but it's possible to break just about any file
> system if you work hard enough at it.
Yep. They will just break different ways.
> Also, perhaps I misunderstood what Bill was saying, in light of
> Jason's most recent response. Fwiw, I'm no part of releng, so I
> probably shouldn't be speaking to what will or won't happen with ufs
> for 1.6. It also sounds like I didn't quite understand the complexity
> of UBC (I can see why it would be considerably more difficult atop
> LFS than atop FFS).
I don't think it's so much a complexity of UBC, but that because LFS
behaves different, it needs its own versions of routines, whereas most
other FSs can all use the same, not-for-LFS version. So it doesn't
leverage off existing work as much.
> Anyway, the bottom line is that LFS is good for partitions you want
> to be able to write quickly to (including adding files) in bursts,
> but which you won't need to go changing files around on very much.
> Ideal for pkgsrc, not so for cvsroot. Which, I hope, isn't news to
Some cvsroot's might be fine. I think it really depends on how much churn
you do between cleaner runs.