All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gabriel Krisman Bertazi <krisman@collabora.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Theodore Ts'o <tytso@mit.edu>,
	Marco Nelissen <marco.nelissen@gmail.com>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	Ext4 <linux-ext4@vger.kernel.org>,
	Eric Biggers <ebiggers@google.com>
Subject: Re: which lower filesystems are actually supported?
Date: Mon, 03 Jun 2019 01:41:33 -0400	[thread overview]
Message-ID: <85k1e39qeq.fsf@collabora.com> (raw)
In-Reply-To: <CAOQ4uxhbSc0nZ69ffJVfNgVnr=ahg+HetiXcZKMXA2nXKCabqA@mail.gmail.com> (Amir Goldstein's message of "Mon, 3 Jun 2019 02:18:25 +0300")

Amir Goldstein <amir73il@gmail.com> writes:

> On Sun, Jun 2, 2019 at 9:01 PM Theodore Ts'o <tytso@mit.edu> wrote:
>>
>> On Sun, Jun 02, 2019 at 09:42:54AM +0300, Amir Goldstein wrote:
>> > [+cc ext4] Heads up on bug reports "Overlayfs fails to mount with ext4"
>> >
>> > On Sat, Jun 1, 2019 at 11:02 PM Marco Nelissen <marco.nelissen@gmail.com> wrote:
>> > >
>> > > According to the documentation, "The lower filesystem can be any filesystem
>> > > supported by Linux", however this appears to not actually be the case, since
>> > > using a vfat filesystem results in the mount command printing "mount:
>> > > wrong fs type, bad option, bad superblock on overlay, missing codepage or
>> > > helper program, or other error", with dmesg saying "overlayfs: filesystem on
>> > > '/boot' not supported".
>> > > (that's from ovl_mount_dir_noesc(), when ovl_dentry_weird() returns nonzero)
>> >
>> > Specifically for vfat it is weird because of
>> > dentry->d_flags & (DCACHE_OP_HASH | DCACHE_OP_COMPARE)
>> > because it is case insensitive.
>>
> [...]
>> >
>> > I am guessing when people start using case insensitive enabled ext4,
>> > this problem
>> > is going to surface, because the same ext4 (e.g. root fs) could be
>> > used for samba
>> > export (case insensitive) and docker storage (overlayfs).
>>
> [...]
>>
>> We *might* be able to only set the dentry functions on directory
>> entries belonging to directories which have the casefold flag set,
>> instead of simply setting it on all ext4 dentry entries.  But still
>> won't change the fact that overlayfs is going to have case
>> insensitivity support if we want the combination of overlayfs &&
>> casefold to be supported.
>>
>
> My intention was not that overlayfs should support casefold, just that
> an isolated casefold subdir in an ext4 fs shouldn't make the entire fs
> not usable with overlayfs.

That is a reasonable request.  I discussed a bit with Ted about how to
not set dentry functions filesystem wide,  because that gets in the way
of fscrypt.  I don't have a definite answer on how to do it, but it is
something that I will try to fix to enable fscrypt+casefold support.

> Incidentally, we already ran into a similar issue with ext4 encryption.
> Issue was reported by OpenWRT developers and fixed by:
> d456a33f041a fscrypt: only set dentry_operations on ciphertext dentries
>
> I recon casefold is taking a similar direction to the fs/crypto library, so
> solution should be similar as well.
>
> BTW, is casefold feature mutually exclusive with encryption feature?
> Because if it isn't, d_set_d_op() in __fscrypt_prepare_lookup() is
> going to WARN_ON dentry already has ext4_dentry_ops.

Not yet, and that is part of the reason. Right now, these two features
cannot be enable simultaneously, but it is on my todo list to support
that case.

> Thanks,
> Amir.

-- 
Gabriel Krisman Bertazi

      reply	other threads:[~2019-06-03  5:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-01 20:01 which lower filesystems are actually supported? Marco Nelissen
2019-06-02  6:42 ` Amir Goldstein
2019-06-02 18:00   ` Theodore Ts'o
2019-06-02 20:00     ` Amir Goldstein
2019-06-02 23:18     ` Amir Goldstein
2019-06-03  5:41       ` Gabriel Krisman Bertazi [this message]

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=85k1e39qeq.fsf@collabora.com \
    --to=krisman@collabora.com \
    --cc=amir73il@gmail.com \
    --cc=ebiggers@google.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=marco.nelissen@gmail.com \
    --cc=tytso@mit.edu \
    /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.