From: Al Viro <viro@ftp.linux.org.uk>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
dhowells@redhat.com, linux-fsdevel@vger.kernel.org
Subject: Re: How to handle non-local renames?
Date: Thu, 28 Sep 2006 14:15:45 +0100 [thread overview]
Message-ID: <20060928131545.GF29920@ftp.linux.org.uk> (raw)
In-Reply-To: <1159448228.5439.26.camel@lade.trondhjem.org>
On Thu, Sep 28, 2006 at 08:57:08AM -0400, Trond Myklebust wrote:
> On Thu, 2006-09-28 at 13:42 +0100, Al Viro wrote:
> > On Thu, Sep 28, 2006 at 08:31:18AM -0400, Trond Myklebust wrote:
> > > > We don't _care_ if lookup() is not from rename. That's OK.
> > >
> > > You can't assume that you can always kill the subdirectories: they may
> > > be in use. Even if no actual processes are using them, I may have
> > > submounts.
> >
> > So what? Actual processes will get -ESTALE and STFU, submounts can
> > bloody well stay where they are; since we don't free dentries, WTF
> > would VFS care? Mark inodes so that nothing would be done to those
> > directories, unhash them and be done with it. umount -l will be
> > able to take them out just fine afterwards. *Or* we could even
> > try and play with detaching them (needed on invalidation anyway).
>
> That would mean that I can in practice unmount directories on your
> client simply by renaming a directory on my client. I can't see how that
> would be acceptable either.
And what are you going to do if I remove it and its ancestors on my client?
next prev parent reply other threads:[~2006-09-28 13:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-17 20:43 How to handle non-local renames? Miklos Szeredi
2006-09-18 16:38 ` Trond Myklebust
2006-09-18 18:00 ` Miklos Szeredi
2006-09-19 8:24 ` Miklos Szeredi
2006-09-22 0:00 ` Trond Myklebust
2006-09-22 6:22 ` Miklos Szeredi
2006-09-28 10:02 ` Al Viro
2006-09-28 10:03 ` Al Viro
2006-09-28 10:22 ` Miklos Szeredi
2006-09-28 10:16 ` Miklos Szeredi
2006-09-28 10:27 ` Al Viro
2006-09-28 10:53 ` Miklos Szeredi
2006-09-28 11:21 ` Al Viro
2006-09-28 11:44 ` Miklos Szeredi
2006-09-28 11:54 ` Al Viro
2006-09-28 12:31 ` Trond Myklebust
2006-09-28 12:42 ` Al Viro
2006-09-28 12:57 ` Trond Myklebust
2006-09-28 13:15 ` Al Viro [this message]
2006-09-28 13:31 ` Trond Myklebust
2006-09-28 14:20 ` Al Viro
2006-09-28 18:24 ` Trond Myklebust
2006-09-28 20:50 ` Randy Dunlap
2006-09-29 14:55 ` Trond Myklebust
2006-09-29 16:03 ` Randy Dunlap
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=20060928131545.GF29920@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=trond.myklebust@fys.uio.no \
/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.