commit ee159ed497bd07cf60c8981d87e2953014989841
Author: Rachita Kothiyal <[EMAIL PROTECTED]>
Date:   Wed Apr 2 16:40:31 2008 -0400

    Unionfs: don't purge lower sb data on remount
    
    This is no longer needed, as we don't have upper and lower pages.  Plus this
    was racy, requiring the unexported inode_lock variable.
    
    Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>

diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index cbb21b1..8f9ea7d 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -291,17 +291,6 @@ static inline void purge_inode_data(struct inode *inode)
         */
 }
 
-void purge_sb_data(struct super_block *sb)
-{
-       struct inode *inode;
-
-       list_for_each_entry(inode, &sb->s_inodes, i_sb_list) {
-               if (inode->i_state & (I_FREEING|I_WILL_FREE))
-                       continue;
-               purge_inode_data(inode);
-       }
-}
-
 /*
  * Revalidate a single file/symlink/special dentry.  Assume that info nodes
  * of the dentry and its parent are locked.  Assume that parent(s) are all
diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index 6741510..a822456 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -765,10 +765,12 @@ out_no_change:
         * function).  This revalidation will happen lazily and
         * incrementally, as users perform operations on cached inodes.  We
         * would like to encourage this revalidation to happen sooner if
-        * possible, so we try to invalidate as many other pages in our
-        * superblock as we can.
+        * possible, so we like to try to invalidate as many other pages in
+        * our superblock as we can.  We used to call drop_pagecache_sb() or
+        * a variant thereof, but either method was racy (drop_caches alone
+        * is known to be racy).  So now we let the revalidation happen on a
+        * per file basis in ->d_revalidate.
         */
-       purge_sb_data(sb);
 
        /* grab new lower super references; release old ones */
        for (i = 0; i < new_branches; i++)
_______________________________________________
unionfs-cvs mailing list: http://unionfs.filesystems.org/
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs-cvs

Reply via email to