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

Linus Torvalds (
Fri, 11 Jul 1997 08:59:13 -0700 (PDT)

On Fri, 11 Jul 1997, Alan Cox wrote:
> > 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.
> I disagree with your "definition" - it contains a clear statement the inode
> isnt in use. That in iteself is useful information


It _would_ be useful information if we didn't have that information
available to us through other means already. The reason the filesystem has
a inode bitmap is because the filesystem isn't so stupid that it would
want to read all inodes to see which ones are in use. So why are people
arguing that fsck should be that stupid?

Don't be stupid about this: _think_ about the issue for a while.

We already have an indicator of whether the inode is in use: the bitmap.
So the _only_ excuse for writing out dtime/i_nlink after deletion is that
it would act as a confirmation of the deletion. With me so far?

So if the _only_ use of the fields is as a confirmation, why do we write
out 128 bytes to disk? If people really think we need a backup for the
inode bitmap, wouldn't it be better to think of it as what it is: just a
backup for the inode bitmap. Am I the only one who thinks that 128 bytes
is overkill when it comes to backing up one bit of information?

I find it especially ludicrous as that backup already exists: in the form
of the directory tree. So now we have _three_ copies of the same
information, and people still think that i_nlink is important?

What about indirect block information? Or even data block information? We
have just one copy of that, and if that gets corrupted we've lost the
data. But no, people worry about n_link which definitely slows us down,
because they want to have a _third_ copy of the same information. My brain

Wake up, people.. Getting rid of dtime + the "n_link = 0" information
would not make the filesystem any less secure, but it _would_ make it