Re: wierd behaviour...

Marc Lehmann (
Fri, 28 Feb 1997 11:58:23 +0100 (MET)

>> I didn't believe it at first, but:
>> main(){ pause(); }
>I think, to identify it actually as a fork related problem, you can try this
>code (I'm sure you won't get disk light flashin in this case):
>main () {
> while ()
> if (!fork ())
> exit (0);
> else sleep (1);
>If you don't get hd lights flashing in this case, you are identifying
>incorrectly the problem.

Ok, after fixing the program, compiling etc.. it didnt get the drive light flashing..


1. this does nothing to disprove it as a fork-related problem
(think: pause() does nothing, fork() does it... even if it has
nothing to do with fork(), it is the cause... maybe a fork()ed
process makes the calling shell behave differently etc..)
2. the problem is real
3. the drive light goes ON and sth. is written to the disk as soon
as I type ^C


1. we have a problem
2. it may even be shell-related, maybe the calling shell does sth. when
the program returns
3. instead of trying to prove that people are too dumb to distinguish
atime updates from irregular writes, we should try to look after this

as for atime updates... a minimum of 19 blocks are written... big
inode, that. Since the amount written is not always the same,
we may even have an irregular buffer cache write..

maybe there is a sync() somewhere in bash thats triggered that way?
(remember df... mine doesn't sync, but I bet every other's
does... when do the maintainers of df see that it isnt
mnecessary to sync() under linux...)

----==-- _
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ /
-=====/_/_//_/\_,_/ /_/\_\
The choice of a GNU generation