No.
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
hurts.
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
faster.
Linus