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