Re: [autofs] Execute script on expire.
Thank you for response. I simply forgot to CC the list. Now it should work. This is a simplified situation of using automatic squashfs container generation with autofs. --- User: john. autofs path to make squashfs: /makesqfs access mask: /makesqfs// autofs path to access sqfs: /usercontainers access mask: /usercontainers// John wants to put one of his folders (/home/john/foldertoprocess) in a secure storage as a squashfs container which can be accessed automatically anytime. he could make it by isssuing regular command mksquashfs - and copy resulted file to secure storage. be he wants to use something simpler and robust. Instead, John issues the following command: cp /home/john/foldertoprocess /makesqfs/john/marketanalyzis after some time he (and may be other users in the system) can access his securely stored and read only files by following this symbolic link /containers/john/marketanalyzis what happens on backend? == when he copies files to /makesqfs/john/marketanalyzis autofs executes a script that prepares temporary folder somewhere (/tmp/john/marketanalyzis) and mounts it as /makesqfs/john/marketanalyzis when copying finishes and timeout of 5 minutes of inactivity fires in autofs, it executes a designated script and passes /makesqfs/john/marketanalyzis as a parameter. script makes a squashfs container marketanalyzis.sfs and puts it somewhere in secure location, and then makes a symbolic link at /containers/john/marketanalyzis which points to /usercontainers/john/marketanalyzis after script is done, autofs successfully unmounts /makesqfs/john/marketanalyzis Notes: i think script can also remount /makesqfs/john/marketanalyzis as read only before making actual mksquashfs command. with such approach squashfs container creation may be done on separate computer, while mounting part can also be done from different locations. 2008/9/16 Jeff Moyer <[EMAIL PROTECTED]>: > Alexander <[EMAIL PROTECTED]> writes: > >> truly speaking i don't know what is semantics with offset mounts, but >> can describe following situation. >> >> client access the folder /tmpstorage/filestocompress >> it mounts as /tmp/filestocompress (where /tmp is a tmpfs/shmfs or >> unionfs with different underlying mount points) >> client then copies his files there and after time of inactivity >> autofs executes script /bin/compress and after it's completion >> unmounts all corresponding mount points. > > I'm not quite sure I follow. If you could list the steps, taking > automount out of the picture, that would be helpful. So, what is the > ordered list of steps to perform, using *exact* path names. Above, > what's confusing me is that an access to /tmpstorage/filestocompress > would mount anything on /tmp. Autofs simply doesn't work that way. > >> the /bin/compress script does following: >> 0. it gets parameter of what path is going to be unmounted, in our >> example it is /tmp/filestocompress >> 1. makes compressed tar, bzip, or squashfs container from >> /tmp/filestocompress in /users/username/filestocompress.tar >> 2. optionaly deletes all files in /tmp/filestocompress and exits >> >> something like that > > Again, a specific example would be more helpful (with real commands and > paths). > > I'm curious to know why you didn't CC the list on your response. Is it > okay if we continue discussions there? > > Thanks! > > Jeff > -- Sincerely, Alexandr N. ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] autofs Digest, Vol 66, Issue 9
you should put actual numbers instead of $GID and $UID. 2008/9/14 <[EMAIL PROTECTED]>: > Send autofs mailing list submissions to >autofs@linux.kernel.org > > To subscribe or unsubscribe via the World Wide Web, visit >http://linux.kernel.org/mailman/listinfo/autofs > or, via email, send a message with subject or body 'help' to >[EMAIL PROTECTED] > > You can reach the person managing the list at >[EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of autofs digest..." > > > Today's Topics: > > 1. Re: How to use the user mount option (Richard Ray) > > > -- > > Message: 1 > Date: Sat, 13 Sep 2008 14:00:03 -0500 (CDT) > From: Richard Ray <[EMAIL PROTECTED]> > Subject: Re: [autofs] How to use the user mount option > To: autofs@linux.kernel.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 13 Sep 2008, Ian Kent wrote: > >> On Fri, 2008-09-12 at 13:08 -0500, Richard Ray wrote: >>> I feel this must be a simple thing but it is not working for me. >>> In auto.misc I have >>> >>> flash -fstype=auto,rw,sync,flush,user:/dev/sdb1 >>> >>> In auto.master I have >>> >>> /misc file:/etc/auto.misc >>> >>> If I cd /misc/flash the device will mount but all files belong to root >>> If I add uid= to auto.misc the files belong to me >>> Should not the user option do that without specifying a uid >> >> The "user" option is an fstab only option. >> >> So, since autofs specifies the device and the mount point mount(8) >> doesn't consult the fstab. >> >> The only option you have is something like: >> flash -fstype=auto,rw,sync,flush,uid=$UID,gid=$GID:/dev/sdb1 >> >> As long as the requester is a valid user on the system it should mount >> as that user. > > I am a bit less ignorant now but this opens a new can of worms. > Is there documentation for mount options that are not valid in map files? > $GID and $UID are not variables I see when I run env so where do they come > from? > Are there othere variables that can be used in map files? > Can I use something like $(id -u) in a map file? > > Thanks > Richard Ray > > > >> >>> >>> Name: autofs >>> Version : 5.0.2 >>> Release : 27 >>> >>> Fedora 8 >>> kernel: 2.6.24.4-64.fc8 >>> >>> Thanks >>> Richard Ray >>> >>> ___ >>> autofs mailing list >>> autofs@linux.kernel.org >>> http://linux.kernel.org/mailman/listinfo/autofs >> > > > > -- > > ___ > autofs mailing list > autofs@linux.kernel.org > http://linux.kernel.org/mailman/listinfo/autofs > > > End of autofs Digest, Vol 66, Issue 9 > * > -- Sincerely, Alexandr N. ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Execute script on expire.
Hello mailing list, was looking everywhere and could find info on whether or not autofs 4 or 5 has a feature of executing designated script on expire, just before unmounting. -- Sincerely, Alexandr N. ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] autofs unmount don't work with symbolic links
On 02 November 2004, Ian Kent wrote: On Mon, 1 Nov 2004, Denis Vlasenko wrote: > Please use "reply before quote" style. > > On Monday 01 November 2004 11:15, Alexander Ponomarenko wrote: > > I use Debian Linux (testing) and version of automount there is > > Linux automount version 4.0.0 > > But I think this bug is not known and so is not fixed yet even in new > > versions (I didn't find any subject on this question in Internet). > > I can confirm that bug is still there in 4.1.3: > > # automount /mnt/auto > > (/mnt is a symlink) does not expire mounts: > > 13:23:47 * Initializing > 13:23:48 * Starting: automount -f -s -v --timeout 15 /mnt/auto program /root/bin/mapper.sh > 13:23:48 starting automounter version 4.1.3, path = /mnt/auto, maptype = program, mapname = /root/bin/mapper.sh > 13:23:48 using kernel protocol version 3.00 Does this occur with the autofs4 module. We want to see 4.05 instead of 3.00. I saw the same with autofs (3) and autofs4 modules. /etc/auto.master is /var/autofs/local /etc/auto.local --timeout=30 /usr/var/autofs/remote /etc/auto.remote --timeout=300 /usr/var/autofs/mks /etc/auto.mks --timeout=300 where /var is simbolic link to /usr/var. All mounts from /etc/auto.local don't unmounts on expiration time but mounts from /etc/auto.remote and /etc/auto.mks works fine (unmounts on expiration time). The situation is the same as for the version 3 of autofs kernel module, as for the version 4. I can add syslog logs if needed (too mach for posting). -- Alexander Ponomarenko ISD Configuration Management Team E-mail: [EMAIL PROTECTED] ___ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] autofs unmount don't work with symbolic links
I use Debian Linux (testing) and version of automount there is Linux automount version 4.0.0 But I think this bug is not known and so is not fixed yet even in new versions (I didn't find any subject on this question in Internet). On 30.10.2004 23:17, Denis Vlasenko wrote: On Tuesday 26 October 2004 11:33, Alexander Ponomarenko wrote: > Hello! > I found the trouble when I tryed to use autofs on linked var > filesystem. My /var is simbolic link to /usr/var. My filesystems > successfully mounts but didn't unmounts on expiration time. > If I use full path in config files (/uar/var/autofs not simply > /var/autofs) all is OK. > > My operating system is Debian GNU/Linux: > Linux IAPonomarenko 2.6.6-asp #1 Fri Jul 2 11:52:26 EEST 2004 > i686 GNU/Linux. > > I think this information may be usefull for other people. I saw the same on 4.0.0pre10. I worked around by substituting the path symlink points to. I didn't check this on 4.1.3 (forgot about the issue) Which version is yours? -- vda -- Alexander Ponomarenko ISD Configuration Management Team E-mail: [EMAIL PROTECTED] ___ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
[autofs] autofs unmount don't work with symbolic links
Hello! I found the trouble when I tryed to use autofs on linked var filesystem. My /var is simbolic link to /usr/var. My filesystems successfully mounts but didn't unmounts on expiration time. If I use full path in config files (/uar/var/autofs not simply /var/autofs) all is OK. My operating system is Debian GNU/Linux: Linux IAPonomarenko 2.6.6-asp #1 Fri Jul 2 11:52:26 EEST 2004 i686 GNU/Linux. I think this information may be usefull for other people. -- Alexander Ponomarenko ___ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] 2.6 patches broken with 2.6.4
Ian Kent wrote: Thanks for the feedback. How long and in what environment have you been using them. Well admittedly my testing has been with only a few pc's each with about 4-5 shares, none of them SMP boxes. So not at all thorough or stressful compared to what some people on the list are using it for. Alex ___ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] 2.6 patches broken with 2.6.4
The patches have applied cleanly to all kernels up to now, however the second patch (and maybe more, didn't try them since there wasn't any point) won't apply cleanly to kernel 2.6.4. I don't know about anybody else's experience with these patches but I haven't had any trouble with them at all, maybe you should send them to Andrew Morton for inclusion in the -mm branch, That'd save me some patching time for each kernel ;) Keep up the good work! Alex Ian Kent wrote: Hi guys, I have some 2.6 patches. They can be found at http://www.kernel.org/pub/linux/kernel/people/raven/autofs4-2.6 Apply them in number order please. Please leave out the max_anon_2.patch initially. We need to establish what the status of the kernel module is before trying this patch. It was written by Mike Waychison to increase the number of anonymous devices. Once the status patches is established it would be good to how the max_anon patch goes with over 255 mounts and less than about 790 (rpc doesn't allow more than that at the moment). Try as many or as few things as your setup allows and please try and give some coverage of what was used and what went wrong. We need to try this on SMP setups if at all possible. I know I don't need to say this to ypu guys but I will anyway. Please make sure that you do staged testing. What I'm saying is steady as it goes. First a single machine then a couple etc., you know the routine. While the general approach of the patches is the same as what I have used for ages in 2.4 the locking and synchronisation is different and may not be correct (read I think it's not quite right but need evidence to confirm it). Looking forward to your feedback. On Sun, 16 Nov 2003, Chris Croswhite wrote: I can offer up about 75 Linux boxes as testing. They are used pretty heavily mounting about 300-400 differnet mount points during the day from slowlaris, HPsUx, Linux and NetApp file systems. Just let me know. TIA, Chris -Original Message- From: Ian Kent [mailto:[EMAIL PROTECTED] Sent: Sun 16-Nov-03 18:53 To: Alexander Macdonald Cc: [EMAIL PROTECTED] Subject:Re: [autofs] making the mountpoints visible all the time (fwd) On Sun, 16 Nov 2003, Alexander Macdonald wrote: I'm happy to try out any patches, although I'm only using autofs for about 20 or so samba and nfs shares on a few pcs so it wont exactly be thorough enterprise level testing :) In fact, I don't have a 2.6 environment other than what I use to test at home so volenteers are needed for testing. We can't expect the changes to be accepted without some testing other than my simple setup. Any help is appreciated. I'll let you know when I've got something to test. Thanks. ___ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
[autofs] autofs no_local_binds option (nfs <-> bind mounts)
Hi list, autofs (v4,3.1.7-425) is too intelligent ... Directory 'test' is exported via the nfs server on host 'foo' and imported again via the linux automounter locally as soon as 'test' is accessed (corresponding entry in automounter map). The automounter recognizes that 'test' is a local directory and performs a bind mount. Great feature - BUT, there is no way to turn off this functionality. I would need to always have nfs mounts regardless of having the exported directory locally or remotely. In some scenarios (e.g. HA), the nfs server could switch from local to remote, therefore having local binds is not a desirable scenario, there should always be nfs mounts. Is there some kind of workaround or possibiliy to perform such actions, or will the automounter always be smarter that me :-) ? Thanks, Alex - Alexander Marx ___ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] making the mountpoints visible all the time (fwd)
I'm happy to try out any patches, although I'm only using autofs for about 20 or so samba and nfs shares on a few pcs so it wont exactly be thorough enterprise level testing :) In fact, I don't have a 2.6 environment other than what I use to test at home so volenteers are needed for testing. We can't expect the changes to be accepted without some testing other than my simple setup. ___ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] making the mountpoints visible all the time
I'm using kernel 2.6.0-test9, i could only see patches for 2.4 so i guess this has the latest autofs in it allready right? I've also upgraded my daemon to autofs-4.1.0-beta3. I then tried running this:- automount -g /mnt/network/samba/computerA file /etc/autofs/samba in the file /etc/autofs/samba I have this:- download-fstype=smbfs,username=guest,password=none ://computera/Download upload-fstype=smbfs,username=guest,rw,password=none ://computera/Upload it works fine but it still doesnt do the "ghosting" Rigler, Steve wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alexander Macdonald Sent: Friday, November 14, 2003 6:13 AM To: [EMAIL PROTECTED] Subject: Re: [autofs] making the mountpoints visible all the time Ian Kent wrote: The autofs4-2.4 module build kit or the patches contained in it or the patches contained in autofs-4.1.0-beta3 can give you this for some of the maps. NIS, LDAP and file maps work at the moment. I's in the expected place on kernel.org. not sure what you mean by file maps, but I'm trying to mount samba and nfs shares so i guess I'm out of luck... In order to view the mountpoints before they are mounted you need to have the newer version of the kernel module which is available at kernel.org. The maps aren't really specific to the type of filesystem you are trying to mount. You can get your maps from a local file, NIS, LDAP, etc. They can contain information to mount smb, nfs, or even local filesystems. If you install the newer kernel module, you can make your mountpoints visisible with the ghosting option. One way to enable this is to set it in your /etc/auto.master like: /somedir file:/etc/auto.somedir -g Or you can add the "-g" to the "daemonoptions" variable line in /etc/init.d/autofs. -Steve ___ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] making the mountpoints visible all the time
Ian Kent wrote: The autofs4-2.4 module build kit or the patches contained in it or the patches contained in autofs-4.1.0-beta3 can give you this for some of the maps. NIS, LDAP and file maps work at the moment. I's in the expected place on kernel.org. not sure what you mean by file maps, but I'm trying to mount samba and nfs shares so i guess I'm out of luck... ___ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
[autofs] making the mountpoints visible all the time
Hi I've currently got automount setup so that i can cd into a directory like /mnt/someplace and someplace will be automatically created and mounted... it would be quite usefull if that directory was allways visible so that i could browse to it in gui applications... how do i do that? ___ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Re: autofs and nautilus
On Mon, 2003-09-01 at 15:55, Ian Kent wrote: > On 1 Sep 2003, Alexander Larsson wrote: > > > On Sat, 2003-08-30 at 16:55, Ian Kent wrote: > > > Hi all, > > > > > > I have recently taken on maintenance of autofs v4 and am investigating a > > > problem with Nautilus and autofs. > > > > > > It appears that the if the Trash monitor scans the mounts at the time that > > > an expire is happening it remounts the the automount entry. I have spent > > > quite a while developing an understanding of what is happening but I can't > > > think of a way to get around this purely within autofs. I am hoping that > > > a solution can be found in discussion here on the list. > > > > > > Please help. > > > > I'm all for fixing this in Nautilus, however i'm hardly an expert in > > autofs or mounting in general. The nautilus volume handling code is > > pretty gross, and at some point it will probably be rewritten. > > In cooperation with autofs we should be able to sort it out. > > > > > However, is trash scanning really a problem? Don't we only do that on > > startup? > > That's the sort of thing I'm here to find out. > > I'm happy to do more experimentation. > > It appears to me that there is probably a call to stat or the like that > often (sometimes 3 out of 4, sometimes 1 out of 4, then sometimes not a > all) happens when an automount times out, like it is triggered upon > seeing the change in the mount table. This, as it should, causes > a (re)mount to occur. A quick scan over the source gave me the impression > it might be a scan for trash folders but I am by no means sure. One > obvious thought is that it's probably not useful to act on umounts but > rather on mounts. I'm sure it can't be that simple. > > Perhaps a pointer to the relevant bits of code could shed some light on it > for me without the pain of having to go through it bit by bit. There are some different pieces of code involved. The core part of nautilus that tracks mounts and removable volumes is the NautilusVolumeMonitor. The code for this beast (its pretty horrible unfortunately) is in libnautilus-private/nautilus-volume-monitor.c. Basically its a singleton object that emits signals when volumes are mounted/unmounted and the list of removable devices change. The Nautilus part of trash directories are handles by libnautilus-private/nautilus-trash-monitor.c and libnautilus-private/nautilus-trash-directory.c, but the actual searching for trash directories is handled by gnome-vfs in gnome-vfs/modules/file-method.c::find_trash_directory(). However, looking at the code it seems like scanning for trash directories only happen when something actively uses the trash. I think your problems might just be related to how nautilus-volume-monitor.c behaves. There is some autofs magic in mount_volume_nfs_add(), but I really don't know this code all that well, so i can't tell you what its meant to do. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a lonely coffee-fuelled ex-con who must take medication to keep him sane. She's a hard-bitten communist pearl diver with a song in her heart and a spring in her step. They fight crime! ___ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Remote mount with nfs
Hi! Sorry for two things: 01 - I don't speak english, i'm brazilian, but I try. 02 - Maybe this place is not best for my question, but I don't have more hope. I have one LAN using remote X terminals. So, I install and configure the autofs in the workstations and in the X server. But I can't umount the floppy. My server have: auto.master: /var/montag/ /etc/auto.floppy --timeout 30 auto.floppy: floppy_bilbo -fstype=nfs,suid,rw 192.168.247.4:/var/montag/floppy_ws_01 And in the workstation: auto.master: /var/montag /etc/auto.floppy --timeout 30 auto.floppy: floppy_ws_01 -fstype=vfat,suid,rw :/dev/fd0 exports: /var/montag/floppy_ws_01 192.168.247.0/255.255.255.0(rw,root_squash) So, the automount work fine with this configuration. When the station access the directory /var/montag/floppy_bilbo, the server mount with nfs the floppy of station(your own floppy device) and all work fine. But, the autofs no umount the device and I do not have any permission to write in floppy. Whats happend?? I have no idea. In time: if I try umount manually, the umount not work. I need help. []'s Alexander Brazil-Rio de Janeiro [EMAIL PROTECTED] ___ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
Programmable Maps
Hi all, I want to use programmable maps with autofs (RH 7.3, autofs-3.1.7). But how can I write such a map? There's only little information in the man pages. I tried it with a shell-script (bash), that prints an map entry via echo to stdout, but the daemon always said "Looking up for ... failed!". What is the correct method to write a script? Can anyone help me? Thanks in advance Alexander -- -- --- Dipl.-Ing. Alexander von Buelowhttp://www.rcs.ei.tum.de Institute for Real-Time Computersystems (RCS) fon +49/89-289-23556 Technische Universitaet Muenchen, D-80290 Muenchen fax +49/89-289-23555
Re: Files locking -- offtopic
Oops -- it _is_ nfs problem =( But, anyway, could anybody say anything about that (in /var/log/messages): May 6 19:35:59 pegas kernel: call_verify: server accept status: 2 May 6 19:35:59 pegas last message repeated 2 times May 6 19:35:59 pegas kernel: RPC: garbage, exit EIO -- Alexander Koptelov Institute for System Programming, Russian Academy of Sciences e-mail: [EMAIL PROTECTED] icq:36208499
Files locking
Hi there! I can't get lock on file located on filesystem that mounted with automounter. On nfs filesystems mounted with `mount' it works. I'm using autofs-4.0.0. Thanks -- Alexander Koptelov Institute for System Programming, Russian Academy of Sciences e-mail: [EMAIL PROTECTED] icq:36208499
Spaces in directories
Nice time of day!
I've got problem with mounting dirs that contain spaces in it's names
(e.g. `flor:/C/My Music/mp3').
First, in standard auto.net script anything after first space is stripped off
and `/C/My Music/mp3' becomes `/C/My'.
Second, when this was corrected, automounter can't properly parse
mount query `Music/mp3 -fstype=nfs,hard,intr,nodev,nosuid flor:/C/My Music/mp3'
Does anybody know huw to struggle with it or have a patch?
Thanks,
Alexander.
--
Alexander Koptelov
Institute for System Programming, Russian Academy of Sciences
e-mail: [EMAIL PROTECTED]
icq:36208499
Re: Fix for SMP deadlock in autofs4
On Fri, 20 Apr 2001, Linus Torvalds wrote: > > > On Fri, 20 Apr 2001, Jeremy Fitzhardinge wrote: > > > > I kept the dget/put out caution and ignorance, but they're clearly > > problematic. I'm happy to drop them if holding dcache_lock is enough > > to keep the tree stable while I traverse it. > > How does this patch look to you people? > > It's untested, but looks fairly obvious. It removes the increment, and > changes autofs4_expire() to properly bump the count of the returned dentry > (and callers will dput() it when done). This may be unnecessarily careful, > but it's the RightThing(tm) to do. Looks sane for me. However, I would add check for dentry being hashed and would skip the unhashed ones. Otherwise you can get a directory that had been removed but is still busy - doesn't look like a right thing to do. Jeremy? Al
Re: Fix for SMP deadlock in autofs4
On Fri, 20 Apr 2001, Linus Torvalds wrote: > Why are we doing the mntget/dget at all? We hold the spinlock, so we know > they are not going away. Not doing the mntget/dget means that we (a) run > faster and (b) don't have the bug, because we don't need to put the damn > things. > > Comments? It looks like you are right, but I wonder how the hell did that code happen at all. Looks like somewhere around 2.4.0-test10-pre* dcache_lock was moved out of is_tree_busy() and covered dget/dput. Hmm... Might be my fault - I don't remember doing that, but... Anyway, it looks like in that case we can forget about games with ->d_count/->mnt_count. Other cases when we do "safe" dput() under spinlocks are done under _different_ spinlocks, so they are not a problem. Removing that will require an obvious change in is_tree_busy() (shift count by 1). However, the real question is WTF are we trying to get in autofs4_expire() - it returns dentry without grabbing a reference to it. The only thing that saves us is that we have a ramfs-style situation (dentries are pinned until we rmdir) and everything up to the point where we silently forget about dentry is covered by BKL. Since ->rmdir() is under BKL too it's enough, but... Eww... Jeremy, what are you really trying to do there? is_tree_busy() seems to be written in assumption that mnt/dentry is not a mountpoint but root of a subtree with something mounted on its leaves. And autofs4_expire() traverses the list of root's subdirectories, picks one that has nothing busy mounted in _its_ subdirectories and essentially pass the name to caller. Which sends that name (of first-level subdirectory) to userland. Is that what you really want there? It looks very odd - why don't we pass the names of actual mountpoints? What's wrong with the case when foo/bar is busy, but foo/baz is not? Al
Re: Fix for SMP deadlock in autofs4
On Fri, 20 Apr 2001, Jeremy Fitzhardinge wrote: > This is a fix for a potential deadlock in autofs4's expire routine. > It tries to use dput() while holding the dcache_lock. This isn't a > problem in principle since dput() should only try to take the dcache_lock > when the counter makes a transition to zero, which can't happen in > this case. Unfortunately the generic (and only) implementation of > atomic_dec_and_lock always takes the lock, so deadlocks. Frankly, I'd rather add dput_locked() in dcache.c. The bug is real and since autofs4 is not the only place like that... I'll look into that stuff. Al
Mount timeouts
Nice time of day, gentlemen! How can I tell autofs to mount some map with particular timeout when it started on boot? /etc/rc.d/init.d/autofs has ability to pass parameters to _mount_, not to _automount_ daemon.
