块文件对象三种存储类型按外部访问接口而非内部结构划分

存储类型的划分依据不是”数据内部怎么存”，而是”外部通过什么接口访问 数据”——不同的访问接口会反过来影响存储的内部结构、性能和功能。块存储 是最古老的形式，数据存在固定长度的块里，靠SCSI/SATA/iSCSI等协议访问 （iSCSI甚至是建在TCP/IP上、以SCSI作应用层协议）；贴近底层硬件、没有 文件目录权限的负担，性能最优（吞吐高延迟低），但具有排他性——一旦被 某客户端挂载，其他客户端就无法访问，因此Kubernetes里块存储的访问模式 基本只能是RWO。文件存储更贴近人类使用习惯，数据存在长度不固定的文件里， 靠POSIX这一事实标准接口访问；本质是”在块存储之上加了一层组织结构”—— 用文件分配表（FAT）把描述文件由哪些块组成的链表指针集中存放，再往表里 加逻辑位置就成了目录、加访问标志就成了权限，这套标准就是文件系统（如 ext4/XFS/NTFS）；代价是路径要逐级解析查找、权限判断、修改记录等额外 操作会拖累性能。对象存储是最新的形式，随云数据中心兴起，专为非结构化 数据设计——每个对象是”元数据+逻辑数据块”的组合，靠全局唯一标识（常用 UUID）直接访问，天然扁平没有目录概念（虽然常提供Bucket模拟”单层目录” 体验）；由于要先查元数据定位数据块所在的OSD服务器，延迟相对较差，但 多台OSD能同时对外发数据，吞吐量和可扩展性都很出色，且扩展成本极低， 适合CDN这类存放媒体/静态资源的场景。三者是按”性能优先→易用优先→ 扩展性优先”依次演化出来的，没有哪一种能包打天下。

结构图：

flowchart LR
    A["块存储<br/>固定长度块, SCSI/iSCSI等协议"] -->|性能最优, 但排他RWO| A1[适合数据库/操作系统盘]
    A -->|加文件分配表FAT/目录/权限| B["文件存储<br/>POSIX接口"]
    B -->|贴近人类使用, 但路径解析拖累性能| B1[大部分容器工作负载首选]
    C["对象存储<br/>UUID+元数据+数据块"] -->|天然扁平, 多OSD并发吞吐高| C1[适合CDN/媒体/静态资源, 延迟较差]