Messages in this thread | | | From | (Marc Lehmann) | Subject | Re: wierd behaviour... | Date | 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..
but
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
conclusions:
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 problem.
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 --==---/ / _ \/ // /\ \/ / mlehmann@hildesheim.sgh-net.de -=====/_/_//_/\_,_/ /_/\_\ pcg@goof.com The choice of a GNU generation
| |