[PATCH 07/16] btrfs: nuke write_super from comments

[PATCH 07/16] btrfs: nuke write_super from comments

[Artem Bityutskiy]

From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>

The '->write_super' superblock method is gone, and this patch removes all the
references to 'write_super' from btrfs.

Cc: Chris Mason <chris.mason@fusionio.com>
Cc: linux-btrfs@vger.kernel.org
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
---

I expect this patch to be merged via Al Viro's VFS tree.

 fs/btrfs/super.c   |    4 ----
 fs/btrfs/volumes.c |    4 ----
 2 files changed, 8 deletions(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index e239915..ad31627 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -100,10 +100,6 @@ static void __save_error_info(struct btrfs_fs_info *fs_info)
 	fs_info->fs_state = BTRFS_SUPER_FLAG_ERROR;
 }
 
-/* NOTE:
- *	We move write_super stuff at umount in order to avoid deadlock
- *	for umount hold all lock.
- */
 static void save_error_info(struct btrfs_fs_info *fs_info)
 {
 	__save_error_info(fs_info);
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index ecaad40..9f2416c 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1738,10 +1738,6 @@ int btrfs_init_new_device(struct btrfs_root *root, char *device_path)
 
 	device->fs_devices = root->fs_info->fs_devices;
 
-	/*
-	 * we don't want write_supers to jump in here with our device
-	 * half setup
-	 */
 	mutex_lock(&root->fs_info->fs_devices->device_list_mutex);
 	list_add_rcu(&device->dev_list, &root->fs_info->fs_devices->devices);
 	list_add(&device->dev_alloc_list,
-- 
1.7.10

[PATCH 08/16] btrfs: nuke pdflush from comments

[Artem Bityutskiy]

From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>

The pdflush thread is long gone, so this patch removes references to pdflush
from btrfs comments.

Cc: Chris Mason <chris.mason@fusionio.com>
Cc: linux-btrfs@vger.kernel.org
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
---

I expect this patch to be merged via Al Viro's VFS tree.

 fs/btrfs/inode.c        |    3 ++-
 fs/btrfs/ordered-data.c |    2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index a7d1921..ca8b759 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -324,7 +324,8 @@ static noinline int add_async_extent(struct async_cow *cow,
  * If this code finds it can't get good compression, it puts an
  * entry onto the work queue to write the uncompressed bytes.  This
  * makes sure that both compressed inodes and uncompressed inodes
- * are written in the same order that pdflush sent them down.
+ * are written in the same order that the flusher thread sent them
+ * down.
  */
 static noinline int compress_file_range(struct inode *inode,
 					struct page *locked_page,
diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c
index 643335a..051c7fe 100644
--- a/fs/btrfs/ordered-data.c
+++ b/fs/btrfs/ordered-data.c
@@ -596,7 +596,7 @@ void btrfs_start_ordered_extent(struct inode *inode,
 	/*
 	 * pages in the range can be dirty, clean or writeback.  We
 	 * start IO on any dirty ones so the wait doesn't stall waiting
-	 * for pdflush to find them
+	 * for the flusher thread to find them
 	 */
 	if (!test_bit(BTRFS_ORDERED_DIRECT, &entry->flags))
 		filemap_fdatawrite_range(inode->i_mapping, start, end);
-- 
1.7.10

Re: [PATCH 07/16] btrfs: nuke write_super from comments

[cwillu]

> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index ecaad40..9f2416c 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -1738,10 +1738,6 @@ int btrfs_init_new_device(struct btrfs_root *root, char *device_path)
>
>         device->fs_devices = root->fs_info->fs_devices;
>
> -       /*
> -        * we don't want write_supers to jump in here with our device
> -        * half setup
> -        */
>         mutex_lock(&root->fs_info->fs_devices->device_list_mutex);
>         list_add_rcu(&device->dev_list, &root->fs_info->fs_devices->devices);
>         list_add(&device->dev_alloc_list,

Is the locking still required for approximately the same reason?

Re: [PATCH 07/16] btrfs: nuke write_super from comments

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 415 bytes --]

On Wed, 2012-07-25 at 09:46 -0600, cwillu wrote:
> >         mutex_lock(&root->fs_info->fs_devices->device_list_mutex);
> >         list_add_rcu(&device->dev_list, &root->fs_info->fs_devices->devices);
> >         list_add(&device->dev_alloc_list,
> 
> Is the locking still required for approximately the same reason?

I do not know, I assume Chris would check that.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]