Delayed writes on removed files
Root Boy Jim
rbj at icst-cmr.arpa
Sat Apr 30 02:24:01 AEST 1988
From: Amos Shapir <amos at taux01.uucp>
Here is something new for a change: When a file is removed, its blocks
are released to the free list. If any writes were done, some of these
blocks may still be in the buffer pool, waiting for a delayed write.
When such buffers are reallocated, they will be written to the disk,
even though their contents are no longer relevant.
I find this hard to believe. If there *are* blocks waiting to be read,
they must be associated with an inode, which is in core, and is therefore
open by someone. If the file is removed, the link count in core will
still be (at least) one, and I/O should happen normally, even tho the
file has no directory entrys.
The systems I have checked - 4.2 and sysV.3 - make no effort to prevent
this. It seems that in an environment in which many files are created,
written to, and then discarded (e.g. compilation) preventing unnecessary
writes to disk may have a significant effect on overall system
performance. Does anyone know of a system that does this, and how?
When the file *is* finally closed, the inode ref count becomes zero,
and the system should just ignore the delayed write flag and move the
blocks to the free list. Seems simple enuf, but I have not read the
code to check if it in fact does this.
Perhaps it isn't even necessary, as blocks are only allocated on
writes, which then overwrite the old data. I can't imagine that
the old sata would be written first, but truth is stranger than fiction.
Chris, say it ain't so!
Amos Shapir (My other cpu is a NS32532)
National Semiconductor (Israel)
6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261
amos%taux01 at nsc.com 34 48 E / 32 10 N
(Root Boy) Jim Cottrell <rbj at icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
The opinions expressed are solely my own
and do not reflect NBS policy or agreement
.. If I had heart failure right now, I couldn't be a more fortunate man!!
More information about the Comp.unix.wizards
mailing list