Allow file systems supporting ->delete_inode() to call
truncate_inode_pages() on their own. OCFS2 wants this so it can query
the cluster before making a final decision on whether to wipe an inode
from disk or not. In some corner cases an inode marked on the local
node via voting may not actually get orphaned. A good example is node
death before the transaction moving the inode to the orphan dir
commits to the journal. Without this patch, the truncate_inode_pages()
call in generic_delete_inode() would discard valid data for such
inodes.
During earlier discussion in the 2.6.13 merge plan thread, Christoph
Hellwig indicated that other file systems might also find this useful.
IMHO, the best solution would be to just allow ->drop_inode() to do
the cluster query but it seems that would require a substantial
reworking of that section of the code. Assuming it is safe to call
write_inode_now() in ocfs2_delete_inode() for those inodes which won't
actually get wiped, this solution should get us by for now.
Trivial testing of this patch (and a related OCFS2 update) has shown
this to avoid the corruption I'm seeing.
Signed-off-by: Mark Fasheh <[email protected]>
--- linux-2.6.12.orig/fs/inode.c 2005-06-17 12:48:29.000000000 -0700
+++ linux-2.6.12/fs/inode.c 2005-06-28 16:18:52.559820000 -0700
@@ -992,19 +992,21 @@
inodes_stat.nr_inodes--;
spin_unlock(&inode_lock);
- if (inode->i_data.nrpages)
- truncate_inode_pages(&inode->i_data, 0);
-
security_inode_delete(inode);
if (op->delete_inode) {
void (*delete)(struct inode *) = op->delete_inode;
if (!is_bad_inode(inode))
DQUOT_INIT(inode);
- /* s_op->delete_inode internally recalls clear_inode() */
+ /* Filesystems implementing their own
+ * s_op->delete_inode are required to call
+ * truncate_inode_pages and clear_inode()
+ * internally */
delete(inode);
- } else
+ } else {
+ truncate_inode_pages(&inode->i_data, 0);
clear_inode(inode);
+ }
spin_lock(&inode_lock);
hlist_del_init(&inode->i_hash);
spin_unlock(&inode_lock);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
