Why Not ... EROFS

[hsiangkao]

Hi Cong,

At least, I wonder adding a new section to compare with EROFS DAX.
Compared to outdated cramfs and container rootfs, EROFS should be the one to compare honestly.

Actually we already have users to adapt EROFS in this way, why not improve it directly?

[congwang-mk]

I have updated code base with branching support, which also explains why EROFS can't implement this without losing its performance benefits. Please take a look.

[hsiangkao]

Honestly I'm super unsatisfied with your vague analysis, and there are several severe reasons why it cannot work as-is from a real kernel filesystem perspective, e.g. you are still using page cache for mmaped cases (e.g. see your read_folio writepages hooks even without any further digging), but currently all upstream DAX filesystems doesn't; all executable libraries will be mmapped into userspace rather than using POSIX read/write APIs.

There are a lot design problems out of this "filesystem".

Anyway, if you don't want to discuss in a severe way and just use AI to generate nonsense code. I cannot help you in any case.

Of course, I am interested in AI agent filesystems, and upstream EROFS will find a way to reach the goal, but upstream needs a sane approach rather than this broken status.

[hsiangkao]

It doesn't resolve any comments in a valid way, especially
0cb854e
you're still using duplicated page cache for all mmaped I/Os which is absolutely against DAXFS naming.

if you'd like to treat this use cases seriously (and in a technical way), please reopen this rather than close without any comment.

[congwang-mk]

Hi, it has nothing related to this subject. If you find any other issue, please create a separate issue with a proper subject. Thanks.

[hsiangkao]

file reads resolve to direct memory loads with no page cache - false, mmaped I/Os are all in page cache.

DAX filesystems shouldn't use page cache at all, which means even for write mmaped I/Os, you could directly use physical memory instead of page cache.
Unfortunally, currently DAX and page cache cannot be applied to the single in-core inode, which is a fundemental problem out of this approach.

[hsiangkao]

Sorry, you didn't treat the analysis in any serious way, you're just ignoring any comment and cheat random users in vague words,

[congwang-mk]

Hi Xiang. Please create separate issues, otherwise it is not easy for tracking.

Thanks for your understanding.

[hsiangkao]

My last words as a friend, opensource is for collaboration rather than random idea + nonsense implementation, and from the current implementation, I can see you have zero knowledge about how to develop filesystems, sorry about my unfriendly words, but that is the truth.

Your project is totally broken, but you don't want to listen any comments from me.
And you're just want to invest a wheel and if users use it, they will be in very bad status, that is awful, good luck to your project!