From: Al Viro <viro@ZenIV.linux.org.uk>
To: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: sget() misuse in nilfs
Date: Tue, 5 May 2009 09:18:11 +0100 [thread overview]
Message-ID: <20090505081811.GK8633@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20090505.021129.103520156.ryusuke@osrg.net>
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).
next prev parent reply other threads:[~2009-05-05 8:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-03 22:51 sget() misuse in nilfs Al Viro
2009-05-04 17:11 ` Ryusuke Konishi
2009-05-05 8:18 ` Al Viro [this message]
2009-05-05 15:37 ` Ryusuke Konishi
2009-05-05 16:37 ` Al Viro
2009-05-06 6:28 ` Ryusuke Konishi
2009-05-06 16:09 ` Ryusuke Konishi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090505081811.GK8633@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=konishi.ryusuke@lab.ntt.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).