From: Theodore Ts'o <tytso@mit.edu>
To: Dave Chinner <david@fromorbit.com>
Cc: Andreas Dilger <adilger@dilger.ca>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
guy@linux.com, jra@google.com, drosen@google.com,
hch@infradead.org
Subject: Re: [RFC] A proposal for adding case insensitive lookups to ext4
Date: Sun, 6 Nov 2016 19:14:56 -0500 [thread overview]
Message-ID: <20161107001456.muvwkwlqxucrzpzi@thunk.org> (raw)
In-Reply-To: <20161106235722.GG28177@dastard>
I talked to Christoph at the Plumbers Closing party, and he suggested
that we get something simple in first which (a) assumes no on-disk
format changes, (b) does everything in the VFS layer, by using a
MS_CASE_FOLD, uses a case-insensitive dentry hash, and which degrades
to a brute force search in the VFS by using readdir interfaces if the
direct lookup does not succeed, and (c) at least initially assumes
only ASCII.
This could be extended by individual file systems who are willing to
make on-disk format changes.
It could be further extended later to support Unicode, and worse,
different versions of Unicode. (The XFS patches you referenced
support Unicode 7.0.0, and so they are already obsolete. Now we're up
to Unicode 8.0.0. Fun.) The basic issue here is neither Christoph
nor I are paid enough to worry about Unicode, and all of the hacks out
there don't support Unicode anyway. If someone wants to pay Collabra
$$$ to deal with the Unicode nightmare, life is simple if we let it
degrade to brute force search, and they can have that work done under
contract. :-)
If we want to handle on-disk format changes, then the file system
superblock would have to specify whether it's using ASCII, Unicode v7,
Unicode v8, etc., and the kernel would have to provide helper routines
to deal with all Unicode versions that we've ever supported before. I
agree if we go down that path, we should have generic helper functions
ala how we handled encryption. But the idea is get something basic in
first, and then add other support later, incrementally.
Christoph also suggested at the party that we should look at whether
or not Android weird permissions system could be handled using an LSM.
(It would have to be a stackable LSM, layered on top of SELinux.)
That was definitely an intriguing idea, and much more likely to be
sane than trying to use a wrapfs-based hack. The problem is I don't
understand the weird Android permissions model well enough to know
whether or not this is doable, but it's something I may try to take a
look at if I can find enough round tuits.
- Ted
next prev parent reply other threads:[~2016-11-07 0:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-03 17:28 [RFC] A proposal for adding case insensitive lookups to ext4 Theodore Ts'o
2016-11-04 16:14 ` Andreas Dilger
2016-11-04 21:51 ` Theodore Ts'o
2016-11-04 23:12 ` Andreas Dilger
2016-11-06 23:57 ` Dave Chinner
2016-11-07 0:14 ` Theodore Ts'o [this message]
2016-11-07 4:30 ` Dave Chinner
2016-11-07 5:42 ` Theodore Ts'o
[not found] ` <CAEuANoLdZ0STmhp+1voS9K6+Ndkb6zfSWEcc0_thUtDjS8NPwg@mail.gmail.com>
2016-11-05 0:00 ` Theodore Ts'o
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=20161107001456.muvwkwlqxucrzpzi@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=david@fromorbit.com \
--cc=drosen@google.com \
--cc=guy@linux.com \
--cc=hch@infradead.org \
--cc=jra@google.com \
--cc=linux-ext4@vger.kernel.org \
/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