All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Maxim Uvarov <maxim.uvarov@oracle.com>
Cc: linux-nfs@vger.kernel.org, bfields@fieldses.org,
	Trond.Myklebust@netapp.com, john@johnmccutchan.com,
	rlove@rlove.org, eparis@parisplace.org
Subject: Re: [PATCH] NFS/INOTIFY: inotify user when deleting files on nfs
Date: Thu, 15 Dec 2011 21:32:56 +0000	[thread overview]
Message-ID: <20111215213256.GS2203@ZenIV.linux.org.uk> (raw)
In-Reply-To: <4EEA469E.6070307@oracle.com>

On Thu, Dec 15, 2011 at 11:12:30AM -0800, Maxim Uvarov wrote:

> 1. Original VFS code already has "if NFS", in vfs_unlink(). Because
> of code does not call d_delete() it has to call notification from
> d_delete().
> 
> 2. inotify is done on VFS layer. So logically it has to work on all
> file systems.

You are using a very odd meaning of the word "logically", then.  Note
that inotify does *not* work on NFS, no matter what vfs_unlink() would do.
Simply because files are removed on server, not in VFS.  And server does
not notify clients of such removals.  Ergo, any software that relies on
inotify delivering notifications of files being removed is broken on NFS.
That has nothing whatsoever to the layer in kernel where it's handled;
the information asked for is simply not available to client.  Period.

Incidentally, inotify does not work on a bunch of local filesystems,
starting with procfs.  And won't work, unless you are seriously proposing
to generate events on things like open()/dup2()/etc.  In this case we
might very well have objects appearing and disappearing without ever
having had a dentry.

  reply	other threads:[~2011-12-15 21:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-14 22:58 [PATCH] NFS/INOTIFY: inotify user when deleting files on nfs Maxim Uvarov
2011-12-14 22:58 ` Maxim Uvarov
2011-12-14 23:22   ` Al Viro
2011-12-15 19:12     ` Maxim Uvarov
2011-12-15 21:32       ` Al Viro [this message]
2011-12-15 21:52         ` Myklebust, Trond
2011-12-15 22:34           ` Maxim Uvarov
2011-12-15 22:58             ` Myklebust, Trond
2011-12-15 23:27               ` Maxim Uvarov
2011-12-16 20:50                 ` Stef Bon
  -- strict thread matches above, loose matches on Subject: below --
2011-12-14 22:27 Maxim Uvarov
2011-12-15 10:42 ` Boaz Harrosh
2011-12-15 10:42   ` Boaz Harrosh

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=20111215213256.GS2203@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=Trond.Myklebust@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=eparis@parisplace.org \
    --cc=john@johnmccutchan.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=maxim.uvarov@oracle.com \
    --cc=rlove@rlove.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.