linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Raphael Hertzog <hertzog@debian.org>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: linux-unionfs@vger.kernel.org, Guillem Jover <guillem@debian.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] ovl: redirect on rename-dir
Date: Tue, 25 Oct 2016 13:57:48 +0200	[thread overview]
Message-ID: <20161025115748.ydhkkp5cfcdnjzwn@home.ouaza.com> (raw)
In-Reply-To: <1477380887-21333-4-git-send-email-mszeredi@redhat.com>

Hello Miklos,

thanks for your work on this patch set!

On Tue, 25 Oct 2016, Miklos Szeredi wrote:
> +renaming directories
> +--------------------
> +
> +When renaming a directory that is on the lower layer or merged (i.e. the
> +directory was not created on the upper layer to start with) overlayfs can
> +handle it in two different ways:
> +
> +1) return EXDEV error: this error is returned by rename(2) when trying to
> +   move a file or directory across filesystem boundaries.  Hence
> +   applications are usually prepared to hande this error (mv(1) for example
> +   recursively copies the directory tree).  This is the default behavior.
> +
> +2) If the "redirect_dir" feature is enabled, then the directory will be
> +   copied up (but not the contents).  Then the "trusted.overlay.redirect"
> +   extended attribute is set to the path of the original location from the
> +   root of the overlay.  Finally the directory is moved to the new
> +   location.

>From this, I understand that we will have to add "redirect_dir" to the
mount options for this feature to work. Is there any reason why you
put this as an opt-in feature?

Do you plan to make it the default in the future when it has been
available for a while?

Barring any regression introduced by your patch, it seems that the feature
is best available by default since it allows legitimate operations to
succeed that are otherwise refused. I understand that it makes it
impossible to mount the overlay filesystem with an older kernel but is
that problem more widespread than the one we're fixing here?  On my side,
overlayfs is only used in scenarios where the kernel is always the same
(or newer compared to what created the initial filesystem).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

  reply	other threads:[~2016-10-25 12:05 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-25  7:34 [PATCH 0/3] overlayfs: allow moving directory trees Miklos Szeredi
2016-10-25  7:34 ` [PATCH 1/3] ovl: check fs features Miklos Szeredi
2016-10-25 11:24   ` Amir Goldstein
2016-11-05 20:40     ` Amir Goldstein
2016-10-25  7:34 ` [PATCH 2/3] vfs: export vfs_path_lookup() Miklos Szeredi
2016-10-25  7:34 ` [PATCH 3/3] ovl: redirect on rename-dir Miklos Szeredi
2016-10-25 11:57   ` Raphael Hertzog [this message]
2016-10-26 11:12     ` Miklos Szeredi
2016-10-28 12:56       ` Raphael Hertzog
2016-10-28 12:59         ` Miklos Szeredi
2016-11-06 19:14       ` Konstantin Khlebnikov
2016-11-07  8:07         ` Miklos Szeredi
2016-11-07  9:58           ` Konstantin Khlebnikov
2016-11-07 10:04             ` Miklos Szeredi
2016-11-07 10:08               ` Konstantin Khlebnikov
2016-11-07 13:38                 ` Amir Goldstein
2016-11-10 22:56                   ` Amir Goldstein
2016-11-11  9:46                     ` Konstantin Khlebnikov
2016-11-11 10:06                       ` Miklos Szeredi
2016-11-11 12:42                         ` Amir Goldstein
2016-11-13  9:11                           ` Amir Goldstein
2016-11-07 11:03         ` Raphael Hertzog
2016-11-07 11:31           ` Konstantin Khlebnikov
2016-11-07 13:42             ` Raphael Hertzog
2016-11-10 22:39               ` Miklos Szeredi
2016-11-11  9:41                 ` Konstantin Khlebnikov
2016-11-13 10:00                 ` Amir Goldstein
2016-11-14 16:25                   ` Amir Goldstein
2016-11-16 22:00                     ` Miklos Szeredi
2016-11-18 15:37                       ` Amir Goldstein
2016-11-20 11:39                         ` Amir Goldstein
2016-11-21  9:54                         ` Miklos Szeredi
2016-11-21 10:13                           ` Amir Goldstein
2016-11-21 10:16                             ` Miklos Szeredi
2016-11-22 13:42                               ` Amir Goldstein
2016-10-25 12:49   ` Amir Goldstein
2016-10-26 11:26     ` Miklos Szeredi
2016-10-26 12:11       ` Amir Goldstein
2016-10-26 12:51         ` Miklos Szeredi
2016-10-26 19:56       ` Amir Goldstein
2016-10-28 16:15   ` Al Viro
2016-11-03 15:50     ` Miklos Szeredi
2016-11-04  9:29       ` Amir Goldstein
2016-11-04 13:48         ` Miklos Szeredi

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=20161025115748.ydhkkp5cfcdnjzwn@home.ouaza.com \
    --to=hertzog@debian.org \
    --cc=guillem@debian.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    /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).