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@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
