From: Miklos Szeredi <miklos@szeredi.hu>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Robo Bot <apw@canonical.com>, Felix Fietkau <nbd@openwrt.org>,
Neil Brown <neilb@suse.de>, Jordi Pujol <jordipujolp@gmail.com>,
ezk@fsl.cs.sunysb.edu, David Howells <dhowells@redhat.com>,
Sedat Dilek <sedat.dilek@googlemail.com>,
"J. R. Okajima" <hooanon05@yahoo.co.jp>
Subject: Re: [PATCH 00/13] overlay filesystem: request for inclusion (v16)
Date: Mon, 18 Mar 2013 12:27:15 +0100 [thread overview]
Message-ID: <CAJfpeguhZLQWz4bvyJoaB2BLkzu2Op68_woUaBts2tCqECndcQ@mail.gmail.com> (raw)
In-Reply-To: <20130314225940.GQ21522@ZenIV.linux.org.uk>
On Thu, Mar 14, 2013 at 11:59 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> Huh?
> * from st_mode point of view, it's not going to conflict with
> anything; FFS "entry type" matches bits 12..15 of mode_t, and the value
> picked by whoever had first implemented whiteouts had been chosen so
> that it would not clash with any existing values. We have
> #define S_IFMT 00170000
> #define S_IFSOCK 0140000
> #define S_IFLNK 0120000
> #define S_IFREG 0100000
> #define S_IFBLK 0060000
> #define S_IFDIR 0040000
> #define S_IFCHR 0020000
> #define S_IFIFO 0010000
> and this sucker would've been 0160000; new filesystem object types are not
> frequently introduced, to put it mildly, so I wouldn't expect clashes.
I'm worried exactly because new filetypes are introduced so
infrequently. No such thing happened during the lifetime of Linux,
AFAICT. Backup/restore tools are not going to handle it. File
managers are not going to show anything sane (and quite possibly some
will simply crash).
Yes, all that can be fixed, but it will be a slow and painful process,
since union/overlay type filesystems are themselves quite specialized
and problems are not going to be shaken out quickly with userspace
interaction. On the other hand if a whiteout is exported to userspace
as a symlink with xattrs, there will be much less of those problems.
BTW I'm not against adding whiteout support to the VFS and possibly to
filesystems to clean up the security uglilness and optimize storage.
But I think the most important aspect is the userspace interface and
I'm far from sure that a new filetype is the best solution here.
Thanks,
Miklos
next prev parent reply other threads:[~2013-03-18 11:27 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-12 15:41 [PATCH 00/13] overlay filesystem: request for inclusion (v16) Miklos Szeredi
2013-03-12 15:41 ` [PATCH 01/13] vfs-add-i_op-dentry_open Miklos Szeredi
2013-03-12 15:41 ` [PATCH 02/13] vfs-export-do_splice_direct-to-modules Miklos Szeredi
2013-03-12 15:41 ` [PATCH 03/13] vfs-introduce-clone_private_mount Miklos Szeredi
2013-03-12 15:41 ` [PATCH 04/13] overlay filesystem Miklos Szeredi
2013-03-12 15:41 ` [PATCH 05/13] overlayfs-add-statfs-support Miklos Szeredi
2013-03-12 15:41 ` [PATCH 06/13] overlayfs-implement-show_options Miklos Szeredi
2013-03-12 15:41 ` [PATCH 07/13] overlay-overlay-filesystem-documentation Miklos Szeredi
2013-03-12 15:41 ` [PATCH 08/13] fs-limit-filesystem-stacking-depth Miklos Szeredi
2013-03-12 15:41 ` [PATCH 09/13] overlayfs-fix-possible-leak-in-ovl_new_inode Miklos Szeredi
2013-03-12 15:41 ` [PATCH 10/13] overlayfs-create-new-inode-in-ovl_link Miklos Szeredi
2013-03-12 15:41 ` [PATCH 11/13] vfs-export-inode_permission-to-modules Miklos Szeredi
2013-03-12 15:41 ` [PATCH 12/13] ovl-switch-to-inode_permission Miklos Szeredi
2013-03-12 15:41 ` [PATCH 13/13] overlayfs-copy-up-i_uid-i_gid-from-the-underlying-inode Miklos Szeredi
2013-03-12 16:49 ` [PATCH 00/13] overlay filesystem: request for inclusion (v16) Sedat Dilek
2013-03-12 20:00 ` Miklos Szeredi
2013-03-12 17:22 ` J. R. Okajima
2013-03-12 20:01 ` Miklos Szeredi
2013-03-12 21:50 ` Linus Torvalds
2013-03-12 22:23 ` Al Viro
2013-03-13 9:42 ` Sedat Dilek
2013-03-13 15:24 ` Miklos Szeredi
2013-03-13 18:52 ` Al Viro
2013-03-13 22:09 ` Miklos Szeredi
2013-03-13 23:19 ` Al Viro
2013-03-14 10:37 ` Miklos Szeredi
2013-03-14 12:57 ` DT_WHT (Re: [PATCH 00/13] overlay filesystem: request for inclusion (v16)) J. R. Okajima
2013-03-14 22:59 ` [PATCH 00/13] overlay filesystem: request for inclusion (v16) Al Viro
2013-03-18 11:27 ` Miklos Szeredi [this message]
2013-03-13 10:09 ` Sedat Dilek
2013-03-13 10:57 ` Miklos Szeredi
2013-03-20 19:41 George Spelvin
2013-03-20 21:32 ` Al Viro
2013-03-22 5:15 ` Rob Landley
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=CAJfpeguhZLQWz4bvyJoaB2BLkzu2Op68_woUaBts2tCqECndcQ@mail.gmail.com \
--to=miklos@szeredi.hu \
--cc=akpm@linux-foundation.org \
--cc=apw@canonical.com \
--cc=dhowells@redhat.com \
--cc=ezk@fsl.cs.sunysb.edu \
--cc=hch@infradead.org \
--cc=hooanon05@yahoo.co.jp \
--cc=jordipujolp@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nbd@openwrt.org \
--cc=neilb@suse.de \
--cc=sedat.dilek@googlemail.com \
--cc=torvalds@linux-foundation.org \
--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).