On Thu 18-11-10 13:33:54, Chris Mason wrote:
> > Can we just delete writeback_inodes_sb_nr_if_idle() and
> > writeback_inodes_sb_if_idle()? The changelog for 17bd55d037a02 is
> > pretty handwavy - do we know that deleting these things would make a
> > jot of difference?
> >
> > And why _do_ we need to hold s_umount during the bdi_queue_work()
> > handover? Would simply bumping s_count suffice?
> >
>
> We don't need to keep the super in ram, we need to keep the FS mounted
> so that writepage and friends continue to do useful things. s_count
> isn't enough for that...but when the bdi stuff is passed an SB from
> something that has the SB explicitly pinned, we should be able to safely
> skip the locking.
>
> Since these functions are only used in that context it makes good sense
> to try_lock them or drop the lock completely.
>
> I think the only reason we need the lock:
>
> void writeback_inodes_sb_nr(struct super_block *sb, unsigned long nr)
> {
> ...
> WARN_ON(!rwsem_is_locked(&sb->s_umount));
The above is the only reason why we need the lock in the call from
->write_begin(). Yes. But:
> We're not going to go from rw to ro with dirty pages unless something
> horrible has gone wrong (eios all around in the FS), so I'm not sure why
> we need the lock at all?
One of the nasty cases is for example: Writeback thread decides inode
needs writeout, so the thread gets inode reference. Then someone calls
umount and gets EBUSY because writeback thread is working. Kind of
unexpected... So generally we *do* need a serialization of writeback thread
and umount / remount. Just in that particular case where we call the
function from ->write_begin(), s_umount is overkill...
Honza
--
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
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
