Re: [Re: several background fsck panics

On Fri, 28 Mar 2003, Terry Lambert wrote:

> David Schultz wrote:
>
> > > o     Implement "soft read-only".  The place that most of
> > >       the complaints are coming from is desktop users, with
> > >       relatively quiescent machines.  Though swap is used,
> > >       it does not occur in an FS partition.  As a result,
> > >       the FS could be marked "read-only" for long period of
> > >       time.  This marking would be in memory.  The clean bit
> > >       would be set on the superblock.  When a write occurs,
> > >       the clean bit would be reset to "dirty", and committed
> > >       to disk prior to the write operation being permitted
> > >       to proceed (a stall barrier).  I like this idea because,
> > >       for the most part, it eliminates fsck, both BG and FG,
> > >       on systems that crash while it's in effect.  The net
> > >       result is a system that is statistically much more
> > >       tolerant of failures, but which still requires another
> > >       safety net, such as the previous solution.
> >
> > I was thinking of doing something like this myself as part of an
> > ``idle timeout'' for disks.  (Marking the filesystem clean after a
> > period of quiescence would actually interfere with ATA disks'
> > built-in mechanism for spinning down after a timeout, which is
> > important for laptops, so the OS would have to track the true
> > amount of idle time.)  Annoyingly, I can never get the disk
> > containing /var to remain quiescent for long while cron is running
> > (even without any crontabs), and I hope this can be solved without
> > disabling cron or adding a nontrivial hack to bio.
>
> We implemented this when we implemented soft updates in FFS under
> Windows at Artisoft.  That was back before ATX power supplies were
> wide spread, and we needed to be tolerant of users who simply
> turned off the power switch, without running the Windows95
> shutdown sequence.
>
> I dunno about cron.  I think it "noticing" crontab changes
> "automatically" has maybe made it too smart for its own good.
>
> Cron updates the "access" time on the crontab file every time it
> runs, which is once a second.  If you disabled this for fstat,
> the problem would go away.  I'm not sure the semantics are OK,
> though.
>
> The old pre-"smarter" cron would not have this problem, as it
> would run on intervals, and sleep for long periods (until the
> next job was scheduled to run), and you had to hit it over the
> head with "kill -HUP" to tell it the file changed.
>
> Probably the correct thing to do is to use old-style long delta
> intervals, and register a kevent interest in file modifications.
>
> The cruddy thing is, if it were really read-only, then the access
> time update wouldn't happen.  Catch-22.
>
> I think maybe it's useful to distinguish the POSIX semantics here:
> "shall be scheduled for update" is not the same thing, really, as
> "shall be updated".  So, in practice, you could cache the access
> time update for long periods, as long as the correct time was
> marked in memory, and the write is scheduled to occur "eventually".
> So it's possible there is an "out", without having to worry about
> fixing cron so it's not so darn aggressive.

What about using an md for holding crontabs on laptops?

Regards,

> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landmark, LLC. | http://siliconlandmark.com/    >