Date: Wed, 11 Aug 2004 13:37:34 +0200 (CEST) From: Jan Srzednicki <w@wrzask.pl> To: FreeBSD-gnats-submit@FreeBSD.org Subject: bin/70297: request to make amd timeouts per-mount local Message-ID: <20040811113734.0E199E6@zikkurat.wrzask.pl> Resent-Message-ID: <200408111140.i7BBeNXR088458@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 70297 >Category: bin >Synopsis: request to make amd timeouts per-mount local >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Wed Aug 11 11:40:23 GMT 2004 >Closed-Date: >Last-Modified: >Originator: Jan Srzednicki >Release: FreeBSD 5.2-CURRENT i386 >Organization: oak.pl >Environment: System: FreeBSD zikkurat.wrzask.pl 5.2-CURRENT FreeBSD 5.2-CURRENT #4: Wed Aug 4 18:17:00 CEST 2004 root@zikkurat.wrzask.pl:/usr/obj/usr/src/sys/SIN i386 >Description: 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). >How-To-Repeat: >Fix: 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. >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040811113734.0E199E6>