From: Valerie Aurora <vaurora@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Jamie Lokier <jamie@shareable.org>,
jblunck@suse.de, dwmw2@infradead.org, viro@zeniv.linux.org.uk,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
tytso@mit.edu, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 13/35] fallthru: ext2 fallthru support
Date: Wed, 21 Apr 2010 17:38:43 -0400 [thread overview]
Message-ID: <20100421213843.GE5041@shell> (raw)
In-Reply-To: <E1O4WKa-0003Pp-0y@pomaz-ex.szeredi.hu>
On Wed, Apr 21, 2010 at 11:34:52AM +0200, Miklos Szeredi wrote:
> On Wed, 21 Apr 2010, Jamie Lokier wrote:
> > Hmm. I smell potential confusion for some otherwise POSIX-friendly
> > userspaces.
> >
> > When I open /path/to/foo, call fstat (st_dev=2, st_ino=5678), and then
> > keep the file open, then later do a readdir which includes foo
> > (dir.st_dev=1, d_ino=1234), I'm going to immediately assume a rename
> > or unlink happened, close the file, abort streaming from it, refresh
> > the GUI windows, refresh application caches for that name entry, etc.
> >
> > Because in the POSIX world I think open files have stable inode
> > numbers (as long as they are open), and I don't think that an open
> > file can have it's name's d_ino not match the inode number unless it's
> > a mount point, which my program would know about.
> >
> > This plays into inotify, where you have to know if you are monitoring
> > every directory that contains a link to a file, to know if you need to
> > monitor the file itself directly instead.
> >
> > Now I think it's fair enough that a union mount doesn't play all the
> > traditional rules :-) C'est la vie.
> >
> > This mismatch of (dir.st_dev,d_ino) and st_ino strongly resembles a
> > file-bind-mount. Like bind mounts, it's quite annoying for programs
> > that like to assume they've seen all of a file's links when they've
> > seen i_nlink of them.
> >
> > Bind mounts can be detected by looking in /proc/mounts. st_dev
> > changing doesn't work because it can be a binding of the same
> > filesystem.
> >
> > How would I go about detecting when a union mount's directory entry
> > has similar behaviour, without calling stat() on each entry? Is it
> > just a matter of recognising a particular filesystem name in
> > /proc/mounts, or something more?
>
> Detecting mount points is best done by comparing st_dev for the parent
> directory with st_dev of the child. This is much simpler than parsing
> /proc/mounts and will work for bind mounts as well as union mounts.
>
> I think there's no question that union mounts might break apps (POSIX
> or not). But I think there's hope that they are few and can easily be
> fixed.
I couldn't have put it better myself.
To expand slightly, if the broken apps are not few and easily fixed,
then we'll go back and make the kernel more complicated. I'd like to
try the simplest version we think will work, first.
Thanks!
-VAL
next prev parent reply other threads:[~2010-04-21 21:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1271372682-21225-1-git-send-email-vaurora@redhat.com>
[not found] ` <1271372682-21225-2-git-send-email-vaurora@redhat.com>
[not found] ` <1271372682-21225-3-git-send-email-vaurora@redhat.com>
[not found] ` <1271372682-21225-4-git-send-email-vaurora@redhat.com>
[not found] ` <1271372682-21225-5-git-send-email-vaurora@redhat.com>
[not found] ` <1271372682-21225-6-git-send-email-vaurora@redhat.com>
[not found] ` <1271372682-21225-7-git-send-email-vaurora@redhat.com>
[not found] ` <1271372682-21225-8-git-send-email-vaurora@redhat.com>
[not found] ` <1271372682-21225-9-git-send-email-vaurora@redhat.com>
2010-04-15 23:04 ` [PATCH 09/35] whiteout: Split of ext2_append_link() from ext2_add_link() Valerie Aurora
2010-04-15 23:04 ` [PATCH 10/35] whiteout: ext2 whiteout support Valerie Aurora
[not found] ` <1271372682-21225-12-git-send-email-vaurora@redhat.com>
[not found] ` <1271372682-21225-13-git-send-email-vaurora@redhat.com>
2010-04-15 23:04 ` [PATCH 13/35] fallthru: ext2 fallthru support Valerie Aurora
2010-04-19 12:40 ` Jan Blunck
2010-04-19 13:02 ` David Woodhouse
2010-04-19 13:23 ` Jan Blunck
2010-04-19 13:30 ` Jamie Lokier
2010-04-19 14:12 ` Jan Blunck
2010-04-19 14:23 ` Valerie Aurora
2010-04-19 14:53 ` Miklos Szeredi
2010-04-20 21:34 ` Jamie Lokier
2010-04-21 8:42 ` Jan Blunck
2010-04-21 9:22 ` Jamie Lokier
2010-04-21 9:34 ` Miklos Szeredi
2010-04-21 9:52 ` Jamie Lokier
2010-04-21 10:17 ` Miklos Szeredi
2010-04-21 17:36 ` Jamie Lokier
2010-04-21 21:34 ` Valerie Aurora
2010-04-21 21:38 ` Valerie Aurora [this message]
2010-04-21 22:10 ` Jamie Lokier
2010-04-22 10:30 ` J. R. Okajima
2010-04-20 21:40 ` Jamie Lokier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100421213843.GE5041@shell \
--to=vaurora@redhat.com \
--cc=dwmw2@infradead.org \
--cc=jamie@shareable.org \
--cc=jblunck@suse.de \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).