> -----Original Message-----
> From: David Herrmann [mailto:dh.herrm...@gmail.com]
> Sent: Thursday, September 18, 2014 1:57 PM
> To: Hoyer, Marko (ADITG/SW2)
> Cc: systemd-devel@lists.freedesktop.org; Harald Hoyer; Kay Sievers
> Subject: Re: [systemd-devel] cdrom_id opens device with O_EXCL, why?
> 
> Hi again
> 
> On Thu, Sep 18, 2014 at 1:34 PM, David Herrmann <dh.herrm...@gmail.com> wrote:
> > I'm putting Harald and Kay on CC, as they added O_EXCL to protect
> > against parallel burning-sessions. Maybe they can tell you whether
> > that is still needed today and whether we can drop it.
> 
> So my conception of O_EXCL was kinda wrong. O_EXCL on block devices fails with
> EBUSY if, and only if, there's someone else also opening the device with
> O_EXCL. You can still open it without O_EXCL. Now, the kernel-internal mount
> helpers always keep O_EXCL for mounted block devices. This way, user-space can
> open block devices via O_EXCL and be sure no-one can mount it in parallel.
> 

Yeah that's true, that's what I found as well. But exactly this parallel try to 
mount
the device while cdrom_id is working is the problem here. I understand that it 
is needed for
some processes to get exclusive access to a device for good reasons (to prevent 
mounting for instance).
I'd like to understand the reason for cdrom_id especially since it gets only 
exclusive access if no
one mounted the device before.

> For your automounter, this means you should just drop the event on EBUSY. If
> udev was the offender, you will get a follow-up event. If fsck was the
> offender, you're screwed anyway as it takes ages to complete (but fsck
> shouldn't be any problem for the automounter, anyway). if anyone else is the
> offender, you have no idea what they do, so you should just fail right away.

I've to think about just kicking the event. My first guess is that it is a kind 
of complicated
because there is a comparable complex state machine in the background. My way 
out would be probably
implementing a retry mechanism for the mounting. That would cover all you 
suggested as well, I guess.

> 
> Regarding lazy-unmount: It'd require kernel support to notice such usage in
> user-space. I don't plan on working on this (and nobody really cares). But if
> there will be a kernel-interface, we'd gladly accept patches to fix cdrom_id.

I'm not really happy with the lazy umount mechanism as well especially with the 
completely untransparent behavior in the background.
But in my case it seems to be the only way out. The thing is that I cannot 
guarantee that some applications just keeps i-nodes of
a mounted sd-card for instance (just "cd"ing into the subtree is enough). But I 
have to react somehow if the card is removed. There are two options:

1. I'm not unmounting the partition.
        - In principal, this is somehow ok (not nice), any further IO access 
leads to IO errors. 
        - Since the mount point is still available, other applications can 
enter as well (ok, but not nice)
        - The shit happens when now someone inserts another sd card
                -> I'm not able to mount the partition (with same number) of 
the new sda card since the device node is still mounted
                -> Applications entering the mount point are getting lots of 
rubbish when they access i-nodes linked to cached parent nodes (the files in 
the root dir for instance)
So this is really not a good way out here.

2. I'm lazy umounting the partition so that the scope is really only limited to 
applications that are keeping i-nodes and only to the i-nodes that are kept.
        - No other application can access the invalid cached i-nodes any more
        - I can mount a new sd card without any problems even if we have the 
same partition number
        - The kept i-nodes are removed automatically when the application 
decides to release them
        - Part of the shit remains:
                -> The application keeping the i-node are getting still rubbish 
in case a new card is inserted. But only this one application.
Well the world is not perfect.

So back to the initial question. Is there still a valid reason why cdrom_id is 
acquiring exclusive access? The cd buring case is at least for me not really a 
problem. If this is the only reason I could simply locally patch it out. But to 
be honest, I can't really imagine how this mechanism could even help with this 
use case ...

> 
> Thanks
> David

Regards,

Marko

_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to