ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: David Howells <dhowells@redhat.com>,
	ksummit-discuss@lists.linuxfoundation.org
Cc: mszeredi@suse.com
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Overlays and file(system) unioning issues
Date: Mon, 27 Jul 2015 14:19:44 +0100	[thread overview]
Message-ID: <1438003184.26913.23.camel@infradead.org> (raw)
In-Reply-To: <28240.1437753683@warthog.procyon.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]

On Fri, 2015-07-24 at 17:01 +0100, David Howells wrote:
> 
>  (1) Whiteouts.
> 
>      Linus's idea that a union layer or overlay mounted not as part of a union
>      but separately, should expose whiteouts as 0,0 chardevs.  Whilst this
>      might indeed make the backup tools easier as things like tar can then use
>      the stat() and mknod() interfaces rather than having to use special
>      ioctls or syscalls, Miklós's idea to implement them as actual 0,0
>      chardevs in the underlying filesystem incurs some problems:

Yeah, this is screwed up. I can kind of understand exposing them to
userspace as 0,0 chardevs in the case where they're mounted outside the
context of a union mount.

But these are *directory entries*, not real inodes. Using chardevs to
implement them *internally* is problematic. It's inefficient, because
it involves an inode lookup and uses up inode#s (in implementations
where that matters), and it's also caused deadlocks in some cases like
JFFS2 where we don't expect the recursion that it requires.

This was much nicer when it was being done with DT_WHT internally. And
you could *still* expose that to userspace as a 0,0 chardev — or
however you like.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

  parent reply	other threads:[~2015-07-27 13:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-24 16:01 David Howells
2015-07-24 16:10 ` David Howells
2015-07-24 16:58   ` Eric W. Biederman
2015-07-24 17:12     ` James Bottomley
2015-07-25 15:39     ` Lai Jiangshan
2015-07-29 13:36     ` Serge E. Hallyn
2015-07-27 13:19 ` David Woodhouse [this message]
2015-07-27 14:33   ` Theodore Ts'o
2015-07-28  7:13     ` Miklos Szeredi
2015-07-28 12:16       ` Theodore Ts'o
2015-10-15 19:49       ` David Howells

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=1438003184.26913.23.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=dhowells@redhat.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=mszeredi@suse.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