文件存储不依赖于块存储吗?

文件存储不依赖于块存储吗?

我通常从事软件工作,对存储不太了解。我读过关于块存储、文件存储和对象存储的文章,我发现所有文章都把存储作为一个完全独立的主题来讨论,而不是包括操作系统会看到的内容——而这才是我真正感兴趣的。

让我感到困惑的是,块存储和文件存储是完全分开的。例如,在 LVM 中,您必须给它提供块设备来管理,然后在其上拥有相应的 VG 和 LV,并在其上拥有文件系统。这些块设备不被视为块存储吗?

当存储人员说文件存储时,该文件存储在某些时候是否一定有块存储在其下方?相反,块存储是否不需要在其上方放置某些东西才能发挥作用?无论是文件系统还是某种对象/专有/特殊存储?

例如,如果我理解正确的话,SAN 有某种控制器,然后控制器会提供 LUN(通常),然后服务器会安装这些 LUN(在操作系统中被视为另一个硬盘),然后将文件系统放在这些 LUN 上。或者这是不正确的?

这看起来很奇怪,因为大多数阅读材料都将它们呈现为看似互相排斥的选项,我不确定我是否误解了一些基本的东西。

答案1

我不是存储专业人士,但我会尽力回答您的问题。

块存储是一种可以以块为单位写入和读取数据的存储,因此得名,传统上它是 512 字节的硬盘扇区,现在现代硬盘可以是 4096 字节的扇区(文件系统块大小可以更大,例如对于 xfs 最大可达 64Kb)

块存储可以划分为不同的分区,即您想要将块存储(1 个硬盘划分为不同的逻辑部分)划分为操作系统层。一个用于启动,一个用于游戏,一个用于数据,一个用于工作。不过,这是可选的,正如您上面提到的 LVM,您可以直接将块存储单元添加为物理卷,而无需对其进行分区。

文件存储是块设备上文件系统的概念,它是一个方便的接口,用于安排和保存/读取该设备的数据,它还允许写入特定块(例如 MBR),让 BIOS api 找到如何启动操作系统,但除此之外,它只是操作系统内核与块设备交互和安排数据的逻辑方式,同时让用户在该存储上拥有良好的基于​​文件的层次结构(unix 中的目录,windows 中的文件夹)

现在您提到的 LVM 只是一个允许您以更有效的方式管理存储的程序(添加、删除、镜像、快照逻辑磁盘),它只是特定操作系统的一个抽象层,用于以更简单的方式与底层硬件存储设备进行交互,类似于 zfs 卷或 Solaris 卷管理器或 linux 软件 RAID(mdraid),所有这些都是为了方便而创建的。

对象存储是一种类似于文件存储的存储,只是存储方式不同,并且具有元数据索引和一些其他机制,可以在不同的硬件内分发数据并存储数据(git,AWS S3)。

我希望这有帮助。

答案2

简化:

  • 块存储公布块(LBA)和读/写块命令。导出块存储的设备意味着另一台机器可以像访问本地磁盘一样访问它并在其上创建文件系统。客户端机器访问原始块。例如,它可以执行某些操作,例如,mkfs.xfs /dev/sdX哪里sdX真的是一个 iSCSI 设备;

  • 文件存储导出目录 (NFS) 或共享 (SMB)。客户端计算机将远程存储视为网络附加目录,从中放入/检索文件。读/写不是针对原始块,而是针对文件。客户端计算机可以访问文件,但不能“格式化”目录/共享本身;

  • 对象存储导出“对象”或二进制数据块,可以使用简化的 GET/PUT API 进行读取/写入 - 想象一下 Web 服务器接受对对象的 GET/PUT 请求,这些对象在底层传统(基于文件或块)设备上检索/存储。这基本上就是 Amazon S3 所做的,导出您可以读取或附加到的存储桶。

使区别变得更加复杂的是,您可以将每种存储类型层叠在一起,或通过另一种存储类型模拟一种存储类型。例如,使用文件存储,可以在文件内创建文件系统,并将生成的文件系统挂载到客户机内。或者,可以使用 GET/POST 接口来模拟块或文件存储。

也就是说,底层存储通常是基于块的(即使对于支持对象存储的少数 HDD,GET/POST 也在内部转换为 LBA 或其他块寻址方案)。

相关内容