[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