[patch] progress with autofs.

[Luke Kenneth Casson Leighton]

On Fri, Sep 24, 2004 at 03:24:45PM +0200, David Zeuthen wrote:
> >  about the only one with any "complexity" is that i'm going to have to
> >  read the /etc/auto.hal file in order to determine the mountpoint and to
> >  always always always add a "volume.automount_point" into the HAL
> >  database rather than bombing out just because the mountpoint entry
> >  happens to already be in /etc/auto.hal.
> > 
> 
> Ok, so the callout (fstab-sync or, as I like it, autofs-sync) writes
> this property. I think that is OK.
 
 *whew*.

 i was a bit worried you wouldn't like it.

> I think it actually may be a nice thing this ends up in a library or
> some other shared facility - I'm taking you refer to the functions for
> dealing with FSTable* structures. Btw, the Volume struct in fstab-sync
> will go away soon; will be replaced by code now in libhal-storage. Also,
> my current plans involve deleting some of the code from fstab-sync that
> helps determine the mount point candidate - this will live in the
> libhal-storage library; e.g. there will be a function 
> 
> char *
> hal_volume_policy_compute_mountpoint(HalDrive *drive, HalVolume *volume,
>                                      HalStoragePolicy *policy)
 

 for autofs... hm.

 hmm... i... yes, i can see _why_ to do that.

 however the logic of computing the mountpoint and actually using it
 is, as you're no doubt aware, seriously intertwined with /etc/mtab
 and who's presently using what.

> I'm guessing the easiest thing at first is to move all the code that can
> be shared in a single .[ch] file pair and share that between the two
> binaries fstab-sync and autofs-sync.
 
 do take a look at what i've done, because although it looks
 like a significant bunch of changes, it really isn't: so _much_
 of the core functionality from main() right through the entire
 program is exactly the same (with a different parameter),
 it hardly warrants an extra binary.

 ... but hey, it's your decision.

> >  ... if i were to take the autofs "script" approach and use
> >  /etc/auto.hal.sh instead, then i would revert some of the changes and
> >  make /etc/auto.hal.sh read an fstab-formatted file instead of an
> >  autofs-style one.
> > 
> >  so there would be even _less_ differences!
> > 
> 
> I think this may be even nicer actually; you script could even query hal
> for details; e.g. if someone (say, K3B or nautilus-cd-burner) has a lock
> on the cdrom drive you never mount the disc.

 hmmmm....  it doesn't have to be a script it could be a program.

 _aksherrlllyy_..... hmmmm *thinks*...  *wiggle eyebrows*.

 let me think about that approach some more: i might just be able to
 get away with two little programs:

 - one that gets run from /etc/hal.d/devices.d which generates
   block.automount_point (a simple version would just take the block
   device name, minus the "/dev/" bit).

   if the scheme is unique (hence using the block device name) i
   wouldn't even need to write anything to a config file

 - another that queries, as you suggest, hal for details.

 is it easy to query hal to obtain a list of UDIs which contain
 a certain string?

 in this way i could 

> This might in fact be the best option?

 well, i've taken this approach, now, so am likely to be sticking with
 it, for now.

> > > So, what I'm thinking is that this is just a third way to enforce policy
> > > using hal. Hence, why I like the separation. Also, the changes to hald
> > > seems to be pretty minimalistic, if any, given your message below, is
> > > this correct? 
> > 
> >  yes, they are minimalistic, and also i'm suggesting additions to the
> >  hal db format so that the impact on expectations of userspace programs
> >  is even less.
> > 
> 
> I'm all open for adding properties as long as we don't change existing
> ones; what I'm not terribly excited about is adding a lot of code that
> deals with policy because the hal daemon needs to stay out of policy. 
> 
> We do kind of support the old UNIX dogma with volume.is_mounted and rely
> on /etc/mtab to update this one. How about this:
> 
>  1. hal callout autofs.hal sets the boolean property
>     volume.is_managed_by_autofs to TRUE 

 ack.

> and the string property
>     volume.mountpoint to where we can access the volume. 

 you can't do that unless you're prepared to change the way hal reacts
 to /etc/mtab.

 i considered briefly changing the state machine... only briefly.

 i think you might have more luck at that than i would ever have:
 i look at the state machine and go "eek".


> It also sets
>     volume.is_mounted to TRUE

 again, my patch leaves the logic of volume.mount_point and
 volume.is_mounted _completely_ alone.

 so HAL still does detection of /etc/mtab going up-and-down.

>  2. The hal daemon respects the volume.is_managed_by_autofs and thus
>     doesn't update the volume.mountpoint, volume.is_mounted properties
 
 up to you: personally i think it's a good idea to still receive
 notifications from /etc/mtab changes _in parallel_ with having
 a separate record volume.automount_point.

 the reason being that even on an autofs-managed mount point, you
 still can (and still may need to) do a "umount -lf" on it.

>  3. The auto.hal.sh script maintains the boolean property
>     volume.is_safe_to_remove with when the volume can be safely removed

 eep?

 why?

 that's the wrong way round.

 if you run umount -lf and delete the volume, HAL should be informing
 the auto.hal.sh (or fstab-fsync) that the volume _is_ going away.

 remember that automount only does "mount on demand"
 and "automatic umount based on a timeout after lack of use".

>  4. The auto.hal.sh script respects if a drive is locked and this wont
>     physically mount the volume (the K3B, n-c-b issue above)
 
 ah.. *thinks.

> >  i think it necessary that volume managers explicity code in support for
> >  autofs-managed partitions.
> 
> Well, if they're autofs-managed there is no need for a desktop program
> to mount the volume :-).

 correct!!!  gotta love it.
 
 and by using fusexmp, there's no need to _unmount_ it either,
 because HAL just takes it away, and fusexmp allows the kernel +
 KDE/Gnome to ... just ... not care!

> Ideally, what I like to see is completely unchanged HAL API from the
> desktop point of view; e.g. programs can rely on volume.is_mounted and
> volume.mountpoint. What happens beneath the hood they need not care
> about. 

 ah.

 i understand.

 *thinks*....

 let me think out loud: are your expectations of userspace
 programs not having to react differently to automounted
 filesystems reasonable?

 take KVM for one: what's the first thing it does when it sees a
 volume.mountpoint alongside volume.is_mounted = false?

 it tries to mount it.

 now, if that was an ordinary mountpoint, it'd be fine.

 but on an autofs mount point it has quite serious consequences.

 running "mount /dev/sdb /media/autofs/usbdisk" will result in
 /media/autofs/usbdisk being looked up, automatically mounted...


 ah, i see - you'd expect /etc/auto.hal.sh (or whatever) to have
 already recorded volume.mountpoint=/media/autofs/usbdisk and
 to have set volume.is_mounted to "true"?

 likewise with unmount, doing an unmount of an autofs mount
 point (e.g. /media/autofs/usbdisk) is superfluous but perfectly
 reasonable (it's mounts that are a problem)

 okay, so i concur: it's a reasonable expectation to only have
 these two bits of info.


> This is not saying they shouldn't support optional properties - e.g. a
> filemanager might displaying a bouncing bomb on top of a volume when
> volume.is_safe_to_remove exists and it is false.
 
 dddddrrrreeeeeeam on! sorry that's flippant but ... grief, relying on
 ordinary users to obey visual clues?  HAH!
 
 naaaah.

 let them damage their data by being stupid enough to take a disk out
 whilst a write is still in progress, they'll soon enough learn not to
 do it again.

 i mean, we can attempt to mitigate against such damage by specifying
 sync,dirsync as two mount options...

 the whole reason why i'm using fusexmp (and giving serious consideration
 to chrooting the entire KDE session onto the userspace filesystem proxy)
 is to get this "stateless" filesystem behaviour which is so essential
 to getting removable volumes back with minimum user disruption.
 
 to allow users to do what they like, and basically "cope" with anything
 they decide to throw at you: _that_ should be the driving force behind
 decisions.  rather than wobbling along on a knife edge hoping that users
 won't press down too hard, or expecting them to only brush their
 fingers at right-angles to the blade.

 l.

-- 
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love.  If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl at lkcl.net"> lkcl at lkcl.net </a> <br />

_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal