bin/70297: request to make amd timeouts per-mount local
w at wrzask.pl
Wed Aug 11 04:40:24 PDT 2004
>Synopsis: request to make amd timeouts per-mount local
>Arrival-Date: Wed Aug 11 11:40:23 GMT 2004
>Originator: Jan Srzednicki
>Release: FreeBSD 5.2-CURRENT i386
System: FreeBSD zikkurat.wrzask.pl 5.2-CURRENT FreeBSD 5.2-CURRENT #4: Wed Aug 4 18:17:00 CEST 2004 root at zikkurat.wrzask.pl:/usr/obj/usr/src/sys/SIN i386
Amd is a daemon that automatically mounts file systems on access
ocasions. It's built into a NFS architecture, but it's use is not
limited to it and it can be used for automounting CD drives, floppies,
wakeing up sleeping (spinned down) and rarely-accessed drives.
It makes much sense to treat all these cases in a different way, all of
them should have different cache duration timeouts and umount intervals.
In case of a CD, they have to be really small to react to CD eject and
to release the CD really fast after the system stopped using it. On the
other hand, spinning the disk down makes sense after an hour or so, as
the spin-up and spin-down process takes some time (and is not that
healthy to the drive itself). Quite another thing is with NFS mounts,
and still, making a distinction between local network ones and really
remote ones makes sense to me.
Of course, I don't want to change any commandline options. Setting -c or
-w should still set global defaults, but these can be overridden in
amd.conf(5), in the per-mount sections (cache_duration and
dismount_interval config options, accordingly).
I've briefly looked into the amd code and it's data structures. As I
understand it, it shouldn't be hard to make the change. The am_node
structure already has local am_timeo and am_timeo_w. Local am_timeo gets
initialized from global options in the init_map() function (in
/usr/src/contrib/amd/amd/map.c). The cf_map_t structure (from
/usr/src/contrib/amd/amd/amd.h) needs to be updated to include both
options. I'm not that familiar with the code to find out where the local
variables from amd.conf are really used (while creating the node), so I
haven't fixed the thing by myself, but I guess it won't be a big effort
for someone familiar with it.
More information about the freebsd-bugs