lkml.org 
[lkml]   [1997]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PATCH to pre-patch-2.1.45: clean_inode needs to reset i_writecount


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.

Linus


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.097 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site