Re: 2.4 kernel tweaking
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
--
/__
\_|\/
/\
Reply to: