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 >
