On Tue, 2009-01-13 at 09:52 -0800, Andrew Morton wrote:
> On Tue, 13 Jan 2009 11:36:16 -0500 Chris Mason <chris.mason@xxxxxxxxxx> wrote:
>
> > > > + bdev = open_bdev_exclusive(device_path, 0, root->fs_info->bdev_holder);
> > > > + if (!bdev)
> > > > + return -EIO;
> > > > +
> > > > + if (root->fs_info->fs_devices->seeding) {
> > > > + seeding_dev = 1;
> > > > + down_write(&sb->s_umount);
> > > > + mutex_lock(&uuid_mutex);
> > > > + }
> > > > +
> > > > + filemap_write_and_wait(bdev->bd_inode->i_mapping);
> > >
> > > I'm surprised that this can be safely done under ->s_umount.
> >
> > btrfs_init_new_device is only called by the add_dev ioctl. That doesn't
> > happen with s_umount held. Or do you mean we should be taking s_umount?
>
> I'm surprised that filemap_write_and_wait() can safely be called under
> sb->s_umount. But I guess filemap_write_and_wait() doesn't take many
> locks, even though it waits a lot.
In this case s_umount shouldn't be held. But, aren't we running
something similar at umount time (entirely unrelated to this code path)?
At any rate, this flush is there to make sure that any mods made by
btrfs-vol -a /dev/xxx are actually on the device before the kernel tries
to add it.
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
