Re: PATCH to pre-patch-2.1.45: clean_inode needs to reset i_writecount

Linus Torvalds (
Thu, 10 Jul 1997 20:34:37 -0700 (PDT)

On Thu, 10 Jul 1997, Theodore Y. Ts'o wrote:
> This _does_ result in "dtime not zero" messages from fsck (which runs at
> each boot), but that's actually because the ext2 "dtime" field is simply
> broken. So you should actually not worry about that message (but anything
> else would be worrysome..).
> What don't you like about the semantics of the dtime field? It's
> "deletion" time, not "unlink" time. So the time in that field is when
> the inode is actually deallocated, not when it is unlinked from the
> directory hierarchy. This causes warnings during an unclean shutdown,
> but you have to run fsck after an unclean shutdown anyway, so it's no
> big deal.

The whole concept of "dtime" is _wrong_.

Reason: it implies you have to write out the inode after deleting it.
Which is just stupid, plain and simple - if we have deallocated the inode
it by definition no longer contains any useful information, so we
shouldn't spend time writing it out to disk.

When I wrote the minix filesystem I made certain that if I create a
temporary file it will result in the absolute minimal number of disk
writes. In fact, temporary files that were deleted quickly enough
generally resulted in only _one_ disk block being updated, and that was
the inode bitmap block (which usually becomes dirty anyway due to other
inode allocations - you seldom have just one temporary file).

I'm very touchy about latency issues, and dtime is a feature that is not
worth writing out the inode.