Date: Wed, 23 Apr 2003 13:15:46 -0400 (EDT) From: Andre Guibert de Bruet <andy@siliconlandmark.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: current@freebsd.org Subject: Re: [Re: several background fsck panics Message-ID: <20030423125117.O59991@alpha.siliconlandmark.com> In-Reply-To: <3E853324.16550524@mindspring.com> References: <20030324215712.GA844@fump.kawo2.rwth-aachen.de> <20030325110843.GF1700@fump.kawo2.rwth-aachen.de> <20030325161632.GB600@lenny.anarcat.ath.cx> <20030328235250.GA22044@HAL9000.homeunix.com> <3E853324.16550524@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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/ >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030423125117.O59991>