On Fri, 25 Feb 2005, Jeff Moyer wrote:
> Hi, Ian,
>
> Thanks for the write-up! One question below.
>
> ==> Regarding [autofs] [RFC] direct mount support re-work for autofs v4;
> [EMAIL PROTECTED] adds:
>
> [snip]
>
> raven> As far as the daemon goes the changes needed to do this are fairly
> raven> straight forward and reduce overall complexity. They amount to
> raven> identifying the direct map in the master map by its key ("/-"),
> raven> adding an additional mount option "direct" to each mount, adding an
> raven> enumeration function to each map lookup module and to the map cache
> raven> module used by autofs v4. Together they will be used to perform
> raven> mounts, expire runs and umounts.
>
> raven> Since a single daemon will handle multiple autofs mounts, we need a
> raven> way to distinguish one from another. This can be done by adding two
> raven> additional kernel message handlers to the daemon for "missing" and
> raven> "expire" events. The new messages will include the ioctl fd that
> raven> autofs uses to communicate with the mount point. The lookup key path
> raven> is not needed in these messages as the lookup information can be
> raven> obtained from the ioctl fd found in the event message. In
> raven> particular, the st_dev together with the st_ino from the stat struct
> raven> should be sufficient for distinct key lookups.
>
> Isn't the message communicated over the ioctl fd? If so, why include this
> data in the message? It seems a bit redundant.
Because the ioctl relates to a particular directory (direct mount point)
of which there may be many.
Each direct mount map entry is a distinct autofs mount with a distinct
ioctl fd.
>
>
> This is as far as I got. I'll try to look at this in more detail next
> week.
Cool.
Ian
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
