On Tue, 5 Dec 2000, Alexander Viro wrote:
>
> Sigh. OK, let me put it that way:
>
> * we _can_ have dirty blocks on the list when inode gets freed.
Agreed.
> * no, CAN_UNUSE will not see them.
CAN_UNUSE() is not used at all for the final forcible removal of an inode
that has no users.
> * no, we do not give a damn about forgetting them.
Indeed. We'd be better off marking them clean, to make sure they never hit
the disk.
> So Stephen is right wrt fsync() (it will not get that stuff on disk).
> However, it's not a bug - if that crap will not end up on disk we
> will only win.
Stephen is _wrong_ wrt fsync().
Why?
Think about it for a second. How the hell could you even _call_ fsync() on
a file that no longer exists, and has no file handles open to it?
By the time we call clear_inode(), fsync() had better not be an issue any
more. The only reason fscyn() could be an issue is if somebody starts
calling clear_inode() left and right, but hey, if that happens your
filesystem would be so FUBAR'ed that you really wouldn't care any more.
Data integrity of "fsync()" is the least of your worries.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Dec 07 2000 - 21:00:13 EST