* Current behaviour of umount on a frozen FS
@ 2013-03-15 19:26 Carlos Maiolino
2013-03-18 17:53 ` Jan Kara
0 siblings, 1 reply; 2+ messages in thread
From: Carlos Maiolino @ 2013-03-15 19:26 UTC (permalink / raw)
To: linux-fsdevel
Cc: Josef Bacik, Eric Sandeen, Dave Chinner, Christoph Hellwig,
Jan Kara, Luiz Capitulino, viro
Hi guys, first, people Cc'ed on the email were also Cc'ed on a thread related to
a similar problem.
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?
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.
I saw some patches from Fernando in the list but looks like the discussion
didn't continue.
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?
Cheers,
--
Carlos
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Current behaviour of umount on a frozen FS
2013-03-15 19:26 Current behaviour of umount on a frozen FS Carlos Maiolino
@ 2013-03-18 17:53 ` Jan Kara
0 siblings, 0 replies; 2+ messages in thread
From: Jan Kara @ 2013-03-18 17:53 UTC (permalink / raw)
To: Carlos Maiolino
Cc: linux-fsdevel, Josef Bacik, Eric Sandeen, Dave Chinner,
Christoph Hellwig, Jan Kara, Luiz Capitulino, viro
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 <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-03-18 22:27 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-15 19:26 Current behaviour of umount on a frozen FS Carlos Maiolino
2013-03-18 17:53 ` Jan Kara
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).