Re: generic_drop_inode

[Christoph Hellwig]

On Mon, Jun 27, 2005 at 03:06:12PM -0700, Mark Fasheh wrote:
> Allowing the file system to make the full decision and call the proper
> function would be fine, but then we'd need generic_forget_inode exported
> too :)

shouldn't be much of a problem if it's actually an _GPL export.

> If a node crashes or otherwise fails to complete the unlink(2) then the
> inode in qusetion will *not* have actually been orphaned. Of course, the
> local node doesn't know this and eventually gets to ocfs2_delete_inode() (via
> the MAYBE_ORPHANED flag) which will do the work of determining whether the
> inode is actually orphaned. The problem is that by the time we've gotten
> there, generic_delete_inode() has done a truncate_inode_pages() which might
> throw out data for a file which otherwise wants it on disk.

As discussed in a different subthread of the 2.6.13 merge plan we'd like to
move towards not having truncate_inode_pages in that place, because reiser4,
hugetlbfs and some other cluster filesystems don't like it either.
But that alone isn't going to help you a lot..

> In fact, because OCFS2 supports POSIX style unlink-while-open across the
> entire cluster, we might get to ocfs2_delete_inode() and during the voting
> process, discover that the file is still open on another node in which case
> we don't want to wipe it but would have lost file data due to the
> truncate_inode_pages() anyway.
> 
> Essentially, we get to ocfs2_delete_inode() before we have a chance to
> take the cluster lock and determine the true state of the inode.  By
> then it is too late.  We really need to be able to make the
> determination before calling generic_drop_inode(), but drop_inode() is
> under the inode lock, and we can't call out to the cluster.  The
> question becomes where and how to do this work?

I don't think that's doable without a major rework of that area of code.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/