[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9047C53C18267742AB12E43B65C7F9F70BCD386E@dggemi505-mbs.china.huawei.com>
Date: Fri, 26 Jan 2018 02:52:28 +0000
From: "Gaoxiang (OS)" <gaoxiang25@...wei.com>
To: Theodore Ts'o <tytso@....edu>, Al Viro <viro@...IV.linux.org.uk>
CC: "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH RFC v2 00/13] NLS/UTF-8 Case-Insensitive lookups for
ext4 and VFS proposal
Hi Ted,
On 2018/1/26 3:32, Theodore Ts'o wrote:
> On Thu, Jan 25, 2018 at 03:16:50AM +0000, Al Viro wrote:
>> On Thu, Jan 25, 2018 at 12:53:36AM -0200, Gabriel Krisman Bertazi wrote:
>>
>>> The second proposal is related to the VFS layer:
>>>
>>> (2) Enable Insensitive lookup support on a per-mountpoint basis,
>>> via a MS_CASEFOLD flag, with the ultimate goal of supporting a
>>> case-insensitive bind mount of a subtree, side-by-side with a
>>> sensitive version of the filesystem.
>>
>> First reaction: No. With the side of HELL NO.
>>
>> Your ultimate goal sounds utterly insane - dcache tree must be shared
>> for all mounts. Moreover, "would these two names refer to the same
>> object" can not be mount-dependent. Not going to happen.
>>
>> Please, post the description of what you are planning to do.
>> Detailed. I'm not saying that it's 100% impossible to do correctly,
>> but I'm _very_ sceptical about the feasibility.
>
> So I can't speak authoratatively about the Collabora's customer
> requirements that drove this particular feature, but I can talk about
> why I am interested in this feature --- although I understand why it's
> hard to do correctly.
>
> Android is currently using a horrible wrapfs scheme to provide case
> insesitive lookups. We talked about this last year at LSF/MM[1]. It
> is using separate dentry entries for the upper and lower layers, and
> it is *definitely* prone to races. Running fsstress on the top and
> lower layers simultaneously is a pretty simple way to induce hilarity,
> although my understanding is that the developers working on it having
> been hammering on it for a while so that the races that cause kernel
> panicks or file system damage are rare. I don't believe they have
> been completely elimniated, because it's not clear to me that any
> wrapfs solution can ever be made race-free.
Sorry for bother, I mean you refer to sdcardfs,
The current Samsung sdcardfs and esdfs are all fsstress broken for many issues,
However we developed an another approach last year, in
https://android-review.googlesource.com/#/c/kernel/common/+/574402/3/Documentation/filesystems/hwsdcardfs.txt
We applied it on HUAWEI Mate 10 (pro), and the complete solution is
https://android-review.googlesource.com/#/q/status:open+project:kernel/common+branch:android-4.4+topic:huawei_sdcardfs
It supports stackable case-insensitive without modifing VFS smoothly,
and we tested fsstress on the top and lower layers at the same time
without any problem.
>
> [1] https://lwn.net/Articles/718640/
>
> The problem is that both the case insensitive and case sensitive
> directory trees are made available to userspace, and for backwards
> compatibility reasons, they can't just make it disappear. Although
> they don't have a Linus Torvalds going all Mr. Shouty about breaking
> userspace, the combined whinging from the App developer ecosystem
> probably can be a fairly good substitute for Linus when they complain
> about compatibility breakages visible to the Android application
> programmer. :-)
>
> So my hope has been to find a way to (a) make wrapfs go away, and (b)
> allow the functionality of case sensitive and case insensitive bind
> mounts of the same underlying file system directories be *somehow*
> supported.
>
> If the answer is that if two files that differ only in case are
> created via the case sensitive mount results in it being undefined
> which file you get when you open, rename, or delete that file via the
> case insensitive mount, that's fine. I think that's what happpens in
> the wrapfs implementation today anyway. It would probably be fine if
> the answer was you get the file with an exact match if it is present,
> but if the two files created on the case sensitive side are "makefile"
> and "Makefile", and you try open/delete "MaKeFiLe" via the case
> insensitive mount, it's undefined which file you get --- that's fine.
We have a solution to solve case-insensitive stackable but without modifing VFS.
Thanks,
>
> Anyone who does that will get everything they deserve, and they get
> that today anyway with the wrapfs or the previous fuse hack anyway.
>
> This may indeed be an O_PONIES style request. And in the worst case,
> Android will continue using an out-of-tree wrapfs solution, and
> hopefully I can fend off people asking me for help when the wrapfs
> code blows up in various not-so-entertainng ways. Which is,
> admittedly, a purely selfish reason for why I would like to see if we
> can give Android folks equivalent functionality to the wrapfs hack in
> a sane, safe, and consensual way. :-)
>
> Cheers,
>
> - Ted
>
Powered by blists - more mailing lists