If "rtroy" supposition was held up disk performance would suffer
dramatically. All OS-es use write caches, including Windows, though you
have the option to turn it off. Not using caches leads to poor disk
performance, especially on multi-user systems, disks with small buffers,
and where you are regularly rewriting the same area.
Also note that applications also use write caches, so even if your OS
didn't cache and you powered off the system you would probably lose data
with the application cache. If you really want data written immediately
don't use "stdio" and do set O_SYNC when you "open()" the file. I've
done so when I've had to and the performance difference is enormous.
If Unix is stupid because of this, all modern computers are stupid. This
is standard computing practice, Bill Gates included.
- Matt
PS: If you have a stable OS like Unix, loss of the cache becomes a
non-issue for the most part.
John Summerfield wrote:
>
> 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.
>
> --
> Cheers
> John Summerfield
>
> Microsoft's most solid OS: http://www.geocities.com/rcwoolley/
>
> Note: mail delivered to me is deemed to be intended for me, for my
> disposition.
>
> ==============================
> If you don't like being told you're wrong,
> be right!
>
> _______________________________________________
> Redhat-devel-list mailing list
> Redhat-devel-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/redhat-devel-list
--
---------------------------------------------------------------------
Matt Fahrner 2 South Park St.
Manager of Networking Willis House
Burlington Coat Factory Warehouse Lebanon, N.H. 03766
TEL: (603) 448-4100 xt 5150 USA
FAX: (603) 443-6190 Matt.Fahrner@COAT.COM
---------------------------------------------------------------------
