From owner-freebsd-current@FreeBSD.ORG Wed Apr 23 10:15:52 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A46737B401 for ; Wed, 23 Apr 2003 10:15:52 -0700 (PDT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5248E43FDF for ; Wed, 23 Apr 2003 10:15:51 -0700 (PDT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (localhost [127.0.0.1]) h3NHFoHE086063; Wed, 23 Apr 2003 13:15:50 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)h3NHFkYU086060; Wed, 23 Apr 2003 13:15:50 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Wed, 23 Apr 2003 13:15:46 -0400 (EDT) From: Andre Guibert de Bruet To: Terry Lambert In-Reply-To: <3E853324.16550524@mindspring.com> Message-ID: <20030423125117.O59991@alpha.siliconlandmark.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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: [Re: several background fsck panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 17:15:52 -0000 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/ >