lkml.org 
[lkml]   [1997]   [Jul]   [11]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateThu, 10 Jul 1997 20:34:37 -0700 (PDT)
FromLinus Torvalds <>
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    [from the cache]
©2003-2008