On Tue, May 05, 2009 at 02:11:29AM +0900, Ryusuke Konishi wrote: > Hi, > On Sun, 3 May 2009 23:51:36 +0100, Al Viro wrote: > > OK, I give up; what _is_ get_sb/remount code supposed to implement? > > Oh, these functions lack spec comments. > > I first explain some specs. (I think part of them should be added on > the code, later) > > The nilfs_get_sb() allocates a new super_block struct (sb) or assigns > an existing sb to the mount point through sget(). For newly allocated > sb it calls nilfs_fill_super() for initialization. > > The following things are supposed here: > 1) Every rw-mount on a device shares the same sb (as usual). OK. That's the first kind of sb; no MS_RDONLY, no SNAPSHOT, snapshot_cno is 0. > 2) Every sb of snapshot is independent with that of rw-mount or other > snapshots if their checkpoint numbers differ. On the other hand, > two or more snapshots having the same checkpoint number share a sb > wherever possible. Umm... That's what, MS_RDONLY, SNAPSHOT, snapshot_cno > 0? > 3) Snapshots are mountable concurrently with a rw-mount, but a > ro-mount is not so because the ro-mount cannot follow changes > brought by the rw-mount. And ro-mount would be MS_RDONLY, no SNAPSHOT, snapshot_cno equal to the nilfs_last_cno()? > b) ro->rw remount is possible only if there is no rw-mount on the > device and the checkpoint number of the ro-mount is latest. Er... How could there be an rw-mount while we have ro one? Your (3) above would seem to prohibit that situation... > c) Remounting snapshot to different checkpoints or rw-mount is not > allowed. Where is the second part checked in the current code? > > Can SNAPSHOT even be there unless you have MS_RDONLY? > > Yes, it can. Nilfs snapshots can exist concurrently with rw-mount. On the same superblock, that is... And AFAICS the answer's "no, it can't" (we can have rw superblock and snapshot superblock at the same time, but those will be different instances of struct superblock). -- 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
