From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: Current behaviour of umount on a frozen FS Date: Mon, 18 Mar 2013 18:53:32 +0100 Message-ID: <20130318175332.GC7852@quack.suse.cz> References: <20130315192638.GA1592@andromeda.usersys.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, Josef Bacik , Eric Sandeen , Dave Chinner , Christoph Hellwig , Jan Kara , Luiz Capitulino , viro@zeniv.linux.org.uk To: Carlos Maiolino Return-path: Received: from cantor2.suse.de ([195.135.220.15]:39772 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752054Ab3CRW1C (ORCPT ); Mon, 18 Mar 2013 18:27:02 -0400 Content-Disposition: inline In-Reply-To: <20130315192638.GA1592@andromeda.usersys.redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri 15-03-13 16:26:39, Carlos Maiolino wrote: > I'm working on a possible bug related with fsfreeze, where after frozen > filesystem is umounted the respective block device can't be mounted again, > returning to userspace, a -EBUSY error. > > Discussing with Eric Sandeen about it, we identified that the current behaviour > is to make filesystem able to be umounted and mounted again; although it's kept > frozen (probably a reference to its superblock is pinned in memory once it's > mounted ?!), we are able to mount it again and thaw it. > > But it raised some questions about what's the expected behaviour of this > situation, should we allow a frozen filesystem to be umounted? If yes, how about > the possibility of a snapshot corruption in case a snapshot is running when > umount is triggered? So Al refused to forbid umounting of frozen fs - he maintains that 'umount -l' should always work. I can see his point although in this case I'm not 100% convinced that the problems this creates aren't worse than failing umount. > Since we are able to mount it again, and the current state is the same before > umount, looks like we keep superblock pinned in memory and data that should have > generated I/O at umount/mount is kept in memory until the filesystem is thawed. Yes. freeze_super() takes active superblock reference and thaw_super() drops it. So until thaw_super() is called, superblock is still fully alive. This has a consequence that although the frozen filesystem is umounted, from fs driver point of view nothing really happens (at least for most filesystems) since ->put_super() is not called. Only filesystems playing tricks with ->mount can notice. So we don't have problems with umount blocking on frozen fs. Similarly mount only attaches live superblock to a directory hiearchy so again no IO is needed. I'm not sure why mount returns EBUSY for you (it used to work for me when I was testing it). > I saw some patches from Fernando in the list but looks like the discussion > didn't continue. Yeah, it's a pity. He did have some useful fixes in his series. It would be good to revive it and push at least the non-controversial parts (only the last two patches had some problems). > What's the current status of this behaviour on fsfreeze? should we allow a > filesystem to be umounted or not? currently, this is allowed, but, is there > something protecting snapshots to be corrupted or is this being handled as an > unlikely situation? As I wrote above, snapshots should be fine... It should be all working, just it is ... somewhat surprising ... from user POV. Honza -- Jan Kara SUSE Labs, CR