On Mon, Oct 14, 2002 at 03:03:08PM -0400, Matej Cepl wrote: > On Mon, Oct 14, 2002 at 07:41:55PM +0100, Nyk Tarr wrote: > > It seems nothing is committed unless there is a dirty block ie > > something, somewhere has changed, however small or seemingly > > insignificant. It would be pretty difficult to stop _all_ disk activity, > > unless a very high percentage of your processes are running elsewhere - > > something like a ssh to another box with few processes still running > > locally. You'd have to stop *logd for example. > > I know, that I won't get much favor with my argument, but > I cannot stop myself from asking: why it is not possible to do > something with Linux, which is possible with other (unnamed) > operating systems? And concerning *logd, I have already stopped > most of them (unless emergency.* and such stuff) or they are > redirected to /dev/xconsole. > > Sorry, for the argument, but it seems to me, that for beauty of > the programmer's logic some functionality (and users) are > sacrificed.
I can't remember an awful lot of the discussion, but ISTR it having something to do with security of data and guessing when to commit dirty blocks and when to leave them lying around in ram. The basics have been summarised by some kind soul elsewhere in this thread: commit is there to make sure the stuff on disk looks like the stuff in ram. If you lengthen commit intervals, you risk having a lot in ram buffers that isn't on the disk at all. This, combined with VM - swap and probably other things I know little about means there are a lot of things going on that can change disk data, or rather the copies of it that are in ram and cause regular commits. Sorry if this doesn't make much sense, I only understand the basics. The links I posted have discriptions from those much better able to describe it than me. hth -- /__ \_|\/ /\
