hal 0.4.2 "Something like that. Tastes the same anyway." released

[David Zeuthen]

On Thu, 2004-12-02 at 13:30 +0100, Sjoerd Simons wrote:
> On Wed, Dec 01, 2004 at 06:44:10PM -0500, David Zeuthen wrote:
> > Hey,
> > 
> > I just released hal 0.4.2 "Something like that. Tastes the same anyway."
> > that fixes a number of small bugs; Here are the changes in short form
> > 
> >  - Only lazy unmount devices if {storage.volume}.policy.should_mount is
> >    TRUE - e.g. don't lazy unmount devices we don't care about
> 
> Wasn't hal supposed to be policy free ;). 

Well, yeah - the unmount trick have been in hal for a long time. I agree
it's somewhat enforcing policy. Ideally, a callout should take care of
this but I don't want to make such a big change in this stable series.

The thing is, if we don't do this then the desktop user gets a very
strange experience if he pulls out a drive that is mounted.

I hope this is OK - you may just patch it out from Debian if you don't
like it.

> If i'm correct the should_mount policy
> item decides whether or not fstab-sync makes an entry in fstab or is there a
> deeper meaning ? 
> 

It can, and should, be used by policy mount wrappers as well. Basically,
the should_mount property says whether we should mount things or not.
This is configurable by the distributor and user in a nice way.

You will note that in the general policy we set should_mount to FALSE
for SCSI drives mostly to avoid dealing with "big iron" boxes that has
several hundreds or several thousands of disks attached to them. Because
right now hal is not mature enough to handle that correctly. 

Note that when Kay's wonderful hotplug and udev work (see linux-hotplug
archives) lands we can change hal to "do the right thing" because we
don't have to listen to two streams of event (e.g. the hotplug.d and
dev.d), we don't need to reorder events, and we don't have to have
complicated logic for dealing with missing events. Things will get
*much* simpler. 

Also, my plan is to move all IO (expect for sysfs) out to separate
processes (fs detection, polling for media, link detection, ACPI battery
monitoring, PMU battery monitoring, whatever etc.) that is invoked by
hald - said processed will use libhal to speak to hald. 

That will solve the nasty issues with hald hanging in state D
(uninterruptible sleep). Instead, on kernel bugs, we will just have
lingering helper processes hanging in state D which is much better than
hald hanging in that state. (yes, this means one separate process per
drive we are polling).

Also, moving IO to separate processes has the benefit that it's *much*
easier lock down what each separate processes is allowed to do (on a
non-selinux systems these are just setuid root, drop privs and only
executable by the hald process).

Btw, the motivation for this particular change (only unmount drives we
care about, e.g. not SCSI drives), was actually that some people with
hundreds and hundreds of disks got bitten by hal unmounting their SCSI
disks because there was a race condition in hald which means that the
hotplug event for "remove /dev/sdq3" was processed 45 minutes after we
received it. In the meantime the user had of course mounted it and then
we went ahead and unmounted fun. That was fun.

I hope this clarifies. I also hope you like my plan above.

> For debian we use a little script in dev.d to lazy unmount volumes (hal doesn't
> run as root). Basically if the device disappears, there is no use in keeping it
> mounted right?
> 

I agree with you but I'm sure that sysadmins of large machines will
probably come up with some *fun* corner cases where this is dangerous. I
could be wrong though.

Cheers,
David


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