It seems like I am another one who needs to pay more attention to the address field when doing a reply :)
I did a reply to Nick instead of BLFS-support. Just for completeness, and for what it's worth, I post the lacking mails of this thread. On 9/24/05, Luca Dionisi <[EMAIL PROTECTED]> wrote: > Thanks a lot Nick (is your name Nick or Matteo?) > > On 9/24/05, Nick Matteo <[EMAIL PROTECTED]> wrote: > > > > I suggest that you have the actual autofs directory be somewhere else, > > eg /var/autofs, and have each mountplace be a symlink in /mnt to > > /var/autofs, > > eg /mnt/cd -> /var/autofs/cd. > > When you do ls /mnt, currently usable devices will be valid symlinks (light > > blue if your ls output is colored) and unusable devices will be invalid > > symlinks (red in ls.) > > Caveat: Doing an ls on /mnt can take a long time this way! > > > > I was thinking about a solution of this type. I didn't know about > the colors of ls being different if the symlink is valid or not. Good. > But, why did you say that ls on /mnt can take a long time? > > > > 2. when I have mounted a cdrom, the timeout (yes, I > > > know I can configure the value) ... is it the only way > > > to remove the cd? I mean, is there no way to remove > > > the cd before the inactivity timeout expires? Even > > > if there is no user or process accessing the files in > > > it? ...ehm, I mean without being root. > > > > Why is this a problem? Just set the timeout lower if it is locking the > > drive. > > If there's no user or process accessing it, it shouldn't be mounted; a > > timeout of two seconds is fine for CDs. > > Ok, I will try that way. > But, I was thinking that if I set a very low timeout and, for example, > a program is looking for a file in the cd every now and then, the > continuous mount and umount of the file system could slow down > the performance. > Anyway, as an unprivileged user I can do a 'cd' in a position inside > the CD and leave that directory when I don't need the cd anymore... > I think this can do the job. Good, again. > > Drop me a line, anyone, if I said something wrong here. > > Luca > On 9/26/05, Nick Matteo <[EMAIL PROTECTED]> wrote: > On Saturday 24 September 2005 10:42, Luca Dionisi wrote: > > Thanks a lot Nick (is your name Nick or Matteo?) > > My first name is Nick ;-) > > > I was thinking about a solution of this type. I didn't know about > > the colors of ls being different if the symlink is valid or not. Good. > > But, why did you say that ls on /mnt can take a long time? > > Well, in order to determine the symlink status, it has to check the media in > all the drives. So whenever you do an ls on /mnt, it hangs while all the > drives spin up and are mounted if available. > > > > Why is this a problem? Just set the timeout lower if it is locking the > > > drive. If there's no user or process accessing it, it shouldn't be > > > mounted; a timeout of two seconds is fine for CDs. > > > > Ok, I will try that way. > > But, I was thinking that if I set a very low timeout and, for example, > > a program is looking for a file in the cd every now and then, the > > continuous mount and umount of the file system could slow down > > the performance. > > Anyway, as an unprivileged user I can do a 'cd' in a position inside > > the CD and leave that directory when I don't need the cd anymore... > > I think this can do the job. Good, again. > > That would work. I have never noticed any performance problems with letting > the drive umount and remount itself, though. It has to spin back up either > way, so the mounting process isn't really noticeable. > > > > > Drop me a line, anyone, if I said something wrong here. > > > > Luca > Thanks again Nick. Apart for the performance, doing a "cd" in the directory of the mount and leaving only when I don't need any more that media, may be useful to avoid that someone else remove the media. Just in the case that one user is accessing the system from a remote host. (rare case!) Luca -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
