On Wed, Oct 29, 2008 at 07:28:12PM +0100, Reinoud Zandijk wrote: > Hiya David, hi folks, > > On Tue, Oct 28, 2008 at 04:24:31AM +0000, David Holland wrote: > > On Mon, Oct 27, 2008 at 05:02:02PM +0100, Reinoud Zandijk wrote: > > > i'm puzzled by the apparent requirement to set the v_specmountpoint of > > the > > > device a FS is mounted on to the mountpoint on mount. All fs's seem to > > > follow it but its function is not clear. > > > > That, and, of course, making sure each block device is used only > > once. > > I haven't checked that but i didn't see references to that yet. I'll give > it a try. > > > > Since NilFS can have multiple mounts on the same device the > > > v_specmountpoint is at best ambiguous if not inadequate. > > > > Erm, what does that mean, and how does it interact with mount and > > fstab? E.g. what's supposed to happen if I mount half a dozen of these > > from /dev/wd0h and then do "umount /dev/wd0h"? > > In NilFS one can mount various on-disc snapshots readonly and the tail > either read-only or read/write. The snapshots themselves are persistent > over reboots and will stay there until manually removed. They are mounted > with `mount_nilfs -o rdonly,-c 40 /dev/vnd0e /mnt2' i.e. with the explicit > checkpoint number of the snapshot. Enhancements like looking for a snaphot > of a few days before now etc. can be made but this is the basic mechanism. The thing is that our kernel's designed to only have block devices mount once. My sugestion is to have the tail always be mounted, and have the block device point to it. Then have any snapshots that mount just leverage the existing tail mount. You really want a nisfs service to grab the device, then have it vend mounts. But that sounds like a lot more work. I am assuming that when you have different snapshots mounted, they all share pages in the buffer cache. So that if you are reading the same file in four snapshots (same blocks on disk), you have four uses of the same blocks in cache. If that's not how it works, then you'd need to do somethign different above. > The list returned by mount(8) lists the multiple mounts of the same device > on the various mountpoints only not yet with their options ... thats > something i aparently need to put some research in. > > Good question as to what will happen on `unmount /dev/wd0h'... that depends > on unmount scanning the mount list and issuing an unmount on all the > matches or that it will only pick the first. Unmounts on the mountpoints > works fine and the device together with the shared core FS data is > refcounted and released on last unreference. > > > It seems like a can of worms much larger than just the mount point > > reference. > > > > > Should I just keep v_specmountpoint NULL for this FS and will that break > > > anything? > > > > I can't say I'd recommend it. > > Well i could try to ensure that it always points to a valid mount say to > the tail mount if its mounted or otherwise to one of the snapshot > mounts.... the only place i got bitten when i had an invalid mountpoint > reference (i.e. not NULL but also not valid) was a WAPBL function > dereferencing it. > > Hope this clears up a bit. Maybe its time to get rid of this abuse of > the v_specmountpoint ;) To be blunt, if anyone's abusing v_specmountpoint, it's you. :-) The problem is you're trying to shove a set relationship (one to many) into a place that we have designed for a 1:1 relationship. The other thing you can look at is our existing snapshot support. While I wouldn't doubt that it's very ffs-centric (and thus not going to be a perfect fit), it should be able to give you ideas about how to handle snapshots with our mount, device, and vnode systems. Take care, Bill
Attachment:
pgpN4uuJ4Z9Bd.pgp
Description: PGP signature