John, The suggestion that knowing what files are open was only intended as a suggestion to completely eliminate any fsck - it wasn't my primary assertion. My primary assertion is: changes to the _structure_ on the disk must be reflected on the disk ASAP. This can be done by many different means, such as journaling - I have some concerns about that, primarily because I don't know enough about particular implementations, but also because I don't particularly like the concept of rebuilding on reboot. Also, it's not necessary to journal: Files-11 is an example of an on-disk file system which was exceptionally robust in terms of speed and data-integrety following a system halt/power outage. Please note that update of file access times is not at all important to me or much anyone else, and I wasn't referring to that. The method by which Files-11, as an example, kept track of open files was to periodically write out a bitmap reflecting the headers (i-nodes) that were open for write access. After the wide-spread addoption of logical block disk access around 1982, it became possible to hand tasks to the disk controller and let it write less important data when convenient and other data instantly. ... I have no idea what modern IDE and SCSI drives do in this regard, but I'd be VERY surprised if they don't present a logical-block view of the world to their users while they do bad-block re-vectoring and so forth. UPSes are not part of this picture, though your point is well taken: disk structures asside, applications like database engines surely preferr to have the system shut down in an orderly manner! -smile- RT -- Richard Troy, Chief Scientist Science Tools Corporation rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/ On Thu, 18 Apr 2002, John Summerfield wrote: > Date: Thu, 18 Apr 2002 07:48:15 +0800 > From: John Summerfield <summer@os2.ami.com.au> > Reply-To: redhat-devel-list@redhat.com > To: redhat-devel-list@redhat.com > Subject: Re: Better File systems? Was Re: XFS - here's the solution > > > rtroy@sciencetools.com said: > > Here's my imperative: Every change to the structure on disk _must_be_ > > written to disk that very instant. On-disk structure changes are _the_ > > most critical aspect. Caching disk structure is fine, but having > > changes in cache that are not yet reflected on disk is, OK, I'll say > > it: STUPID. (Note that I'm _only_ talking about the disk structure, > > not file data.) With a stale cache, if power is cut or any other > > malfeasance occurrs, the entire volume is at risk. FSCK, even if it > > works flawlessly every time, is another silly thing: The file system > > _should_ provide for knowledge of what files were open at the time, > > and a check be made only of them, where that may make sense. (Some > > file systems of the past have not needed _any_ fsck type of checking > > following system failure, and they have been quite reliable.) I remain > > in dumbfounded awe that Unix/Linux has come all this way with such a > > fundamentally flawed file system paradigm. > > > I don't entirely agree with what you say. > > It IS essential that the filesystem on disk structures reflect all the > space used by the file AS WRITTEN TO THE DISK, but the latest changes > to information about a file are not always required. > > For example, every time you access a file the time of that event is > recorded. In most circumstances here is no great harm if that > information is lost, and there's a mount option to not record it at all > so as to improve performance. > > In those cases where data to be written exceed what can be written in a > single write (one sector I think, but there may be cases where you can > write more than one sector at a time) there exists a window where > inconsistent data may written. > > If it's important to reduce that possibility then you need to install a > UPS. To my mind the important point about a UPS is not that it keeps > you up over a power outage (though that is important) but that it > allows you to do an orderly shutdown. > > >
