[udisks] CD-ROM polling failed due to O_EXCL flag (poller.c)

Karel Zak kzak at redhat.com
Tue Mar 1 05:39:04 PST 2011


On Tue, Mar 01, 2011 at 01:44:50PM +0100, Kay Sievers wrote:
> On Tue, Mar 1, 2011 at 13:33, Karel Zak <kzak at redhat.com> wrote:
> > On Tue, Mar 01, 2011 at 01:09:56PM +0100, Kay Sievers wrote:
> >> Btrfs is like a network filesystem, it has no backing device.
> >
> >  but for example NFS is consistent:
> >
> >  $ stat --format "%d" /mnt/store/a
> >  41
> >
> >  $ grep /mnt/store /proc/self/mountinfo
> >  47 20 0:41 / /mnt/store rw,relatime - nfs sr.net.home:/mnt/store rw,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.111.1,mountvers=3,mountport=37090,mountproto=udp,addr=192.168.111.1
> >       ^^^^
> >
> >  so the stat.st_dev is the same like in mountinfo
> 
> Ah, I see what you mean. It's unrelated to the O_EXCL thing here, not
> about the device <-> mount mapping, just some weirdness with btrfs?

 The problem is st_rdev as well as st_dev :-)

 The device<->mount mapping is not so important (it was always tricky), 
 but file<->filesystem mapping is important issue. I don't see reason 
 why stat(2).st_dev is not consistent with /proc/self/mountinfo on
 btrfs.

 Real life example:

  # vim /mnt/test/a

  # fuser -m /mnt/test 

returns nothing, the same test on NFS:

  # fuser -m /mnt/store
  /mnt/store:           2303

the same problem we will see with lsof, etc.

(Now tested on 2.6.38-0.rc6.git0.1.fc16.x86_64.)

    Karel

-- 
 Karel Zak  <kzak at redhat.com>
 http://karelzak.blogspot.com


More information about the devkit-devel mailing list