关于在纯对象接口上做文件系统的分析讨论

开头点题远离元数据与数据剥离，在对象上强作文件系统的方案，那不是方案，那是在本来没问题的对象系统上人为制造问题！

AB Periasamy是minio 的创始人，同时也是glusterfs的创始人，这里是他的技术视频https://techfieldday.com/video/the-philosophy-behind-minio-with-ab-periasamy/

对象存储（如MinIO）和传统文件系统在设计和用途上有显著不同。对象存储是为了大规模数据存储而设计的，主要用于存储非结构化数据，如视频、图片和日志文件等。它优化了数据的持久性和访问效率，通常通过HTTP协议访问数据。

而文件系统则是为了提供低延迟、文件级别的操作（如修改和读取）而设计的。文件系统支持更复杂的数据操作，例如文件锁定、权限控制和目录层次结构。

将对象存储用作文件系统可能会引入性能和一致性的问题，特别是在需要高频、低延迟访问的场景中。因此，尽管技术上可行，但通常不建议将对象存储用作传统的文件系统。如果有更具体的需求或场景，可以更详细地讨论其适应性和潜在的限制。

Periasamy指出，对象存储是为处理非结构化数据而设计的，如照片、视频等，它优化了数据的存储和检索，但不适合执行传统文件系统中常见的高频率、低延迟的文件级操作。他强调，对象存储的优势在于其能够处理大规模数据，而不是处理文件系统的复杂交互​

AB Periasamy 提出了关于在 MinIO 中实施文件接口的担忧，强调了由于适应与文件系统根本不同的对象存储系统而产生的复杂性和潜在问题。对象存储如 MinIO 优化了高吞吐量和可扩展性，主要处理非结构化数据。它基于简化的 RESTful API 模型构建，与文件系统使用的 POSIX 标准有显著差异。这种差异至关重要，因为文件系统处理的操作更复杂，通常需要对象存储系统如 MinIO 所不擅长支持的功能，例如典型的文件系统操作中的高频率、低延迟交互。

MinIO 的方法侧重于最大化对象存储的优势，而不是通过增加与其核心设计原则不一致的功能来过度复杂化。这种专注确保了 MinIO 保持高效、可扩展和有效地满足其预期用例的特性，这些特性可能会因引入传统文件接口而受到影响。

所以说，在类似S3接口之上去强行开发文件系统这个想法可能就已经不合适了，AB Periasamy是minio 的创始人，同时也是glusterfs的创始人，我想他是对分布式文件系统和对象最了解的！国内这些搞元数据分离基于各种对象搞文件系统的，是即破坏数据的安全稳定性，又得不到文件系统该有的性能！谁知道这么做是客户在使用场景错选了存储方案只能后期这么强改呢？还是有这样奇怪的需求呢？