On 2023/1/17 21:56, Giuseppe Scrivano wrote:
Christian Brauner <brauner@xxxxxxxxxx> writes:
...
We looked at EROFS since it is already upstream but it is quite different than what we are doing as Alex already pointed out.
Sigh.. please kindly help me find out what's the difference if EROFS uses some symlink layout for each regular inode? Some question for me to ask about this new overlay permission model once again: What's the difference between symlink (maybe with some limitations) and this new overlay model? I'm not sure why symlink permission bits is ignored (AFAIK)? I don't think it too further since I don't quite an experienced one in the unionfs field, but if possible, I'm quite happy to learn new stuffs as a newbie filesystem developer to gain more knowledge if it could be some topic at LSF/MM/BPF 2023.
Sure we could bloat EROFS and add all the new features there, after all composefs is quite simple, but I don't see how this is any cleaner than having a simple file system that does just one thing.
Also if I have time, I could do a code-truncated EROFS without any useless features specificly for ostree use cases. Or I could just seperate out all of that useless code of Ostree-specific use cases by using Kconfig. If you don't want to use EROFS from whatever reason, I'm not oppose to it (You also could use other in-kernel local filesystem for this as well). Except for this new overlay model, I just tried to say how it works similiar to EROFS.
On top of what was already said: I wish at some point we can do all of this from a user namespace. That is the main reason for having an easy on-disk format for composefs. This seems much more difficult to achieve with EROFS given its complexity.
Why? [ Gao Xiang: this time I will try my best stop talking about EROFS under the Composefs patchset anymore because I'd like to avoid appearing at the first time (unless such permission model is never discussed until now)... No matter in the cover letter it never mentioned EROFS at all. ] Thanks, Gao Xiang
