DragonFlyBSD

As tuxillo wrote in user mailing list, mountd fails to export PFS because call to mountctl (2) fails. Playing with vkernel I learned, that presumable all mountctl calls will fail if the first argument is a mountpoint of slave PFS. It is so because kern_mountctl in sys/kern/vfs_syscalls.c returns EINVAL in this condition (VPFSROOT flag is not set):

/*
 * Must be the root of the filesystem
     */
    if ((vp->v_flag & (VROOT|VPFSROOT)) == 0) {
        vrele(vp);
        return (EINVAL);
     }

I am sending a simple test which will return 0 if invoked with mountpoint of master PFS and -1 if invoked with mountpoint of slave PFS (or any other directory which is not a mountpoint)

Sorry, wrong attachment

Hi,

Yes exactly, but mountctl(2) is doing the right thing. It needs to make sure its setting flags on exportable mounts.
I'm not sure yet what the solution to this might be.

Cheers,
Antonio Huete

Hello.

I'm not sure yet what the solution to this might be

Look at this code in src/sys/vfs/hammer/hammer_inode.c:

/*
323                          * Only mark as the root vnode if the ip is not
324                          * historical, otherwise the VFS cache will get
325                          * confused.  The other half of the special handling
326                          * is in hammer_vop_nlookupdotdot().
327                          *
328                          * Pseudo-filesystem roots can be accessed via
329                          * non-root filesystem paths and setting VROOT may
330                          * confuse the namecache.  Set VPFSROOT instead.
331                          */
332                         if (ip->obj_id  HAMMER_OBJID_ROOT &&
333                             ip->obj_asof  hmp->asof) {
334                                 if (ip->obj_localization == 0)
335                                         vsetflags(vp, VROOT);
336                                 else
337                                         vsetflags(vp, VPFSROOT);
338                         }

Slave PFSes are considered "historical" and therefore VPFSROOT flag is not set. If VPFSROOT or VROOT flag is not set, call to mountctl fails. I attach a path which can solve this situation, but I am not sure if this a right thing to do, because I know nothing of this vfs cache and how it can be "confused".

Well, I am still uncertain as to how this will effect the VFS cache. I've included a new patch that basically does what is suggested... sets VPFSROOT as long as obj_id is HAMMER_OBJID_ROOT. It appears to work in a quick test of a SLAVE. The slave does not appear to be frozen on the export-side. Note that the client-side mount will (should) be a snapshot of the SLAVE as-of when the mount is made, so the client will not see any updates the slave gets until it remounts it. Also, if the history related to the snapshot it does is deleted through normal hammer cleanups, the existing mount will become unstable.

-Matt