基于FUSE的碎片化多媒体文件高效存储与检索系统

沙特国王大学学报基于FUSE的文件系统，用于高效存储和检索碎片化的多媒体文件Wasim Ahmad Bhat沙特阿拉伯麦地那伊斯兰大学计算机和信息系统系阿提奇莱因福奥文章历史记录：接收日期：2022年2022年7月19日修订2022年8月16日接受2022年8月27日在线提供关键词：多媒体流下载文件系统FUSEA B S T R A C T多媒体内容提供商（如网络储物柜）被大量和大尺寸的多媒体文件淹没。Cyberlocker在将文件分割为片段时向最终用户提供服务质量（QoS）下载。然而，在运行中合并这些片段以进行流传输会损害用户的体验质量（QoE）并破坏计算能力。作为一种解决方案，本文提出了一种基于FUSE的文件系统，即fumy，用于将大型多媒体文件有效存储为小尺寸的碎片（用于下载），并虚拟地统一它们以进行高效检索（用于流传输）。讨论了fumy为实现其目标而采用的虚拟统一、命名空间操作和操作重定向等技术。我们还讨论了fumy作为FUSE文件系统的实现细节我们评估了fumy在各种操作和基准测试配置下在扩展文件系统上的性能。我们的研究结果表明，fumy增加了最小的性能开销扩展文件系统时，碎片大小是512 MiB或更高，对ext4文件系统的性能税最少，甚至提高了特定的工作负载和碎片大小的扩展文件系统的性能。我们建议使用ext4文件系统与512 MiB的碎片大小为不同的工作负载，以实现最佳性能的fumy。©2022作者（S）。由爱思唯尔公司出版代表沙特国王大学这是一篇基于CC BY-NC-ND许可证的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。1. 介绍多媒体行业见证了数字内容生成（Bhat，2018）和互联网共享（Aggarwal等人，2021年）。因此，诸如Rapidgator、MEGA等提供诸如下载的文件共享服务的网络锁（Thomson等人， 2018）和流媒体（Ibosiola等人，2018年，多媒体内容变得非常流行。 由这些网络储物柜托管的内容主要包括高度碎片化的多媒体内容（Mahanti等人，2011年）。例如，一项研究（Mahanti等人，2011）发现Rapidshare上的碎片化内容占其字节数的80%，其中30%的文件被分成多个片段，特别是大型视频文件。图1示出了流行的网络锁定器上的内容碎片。cyberlocker的这种碎片化内容是由于它们对文件电子邮件地址：wab. uok.edu.in沙特国王大学负责同行审查由用户上传/下载（Chan等人，2020年）。这迫使用户将一个大的多媒体文件拆分为多个小文件。此外，当用户的文件被下载时，网络储物柜会奖励他们。这鼓励用户拆分文件以获得更多积分（Thomson等人，2018年）。此外，大型多媒体文件（如4K视频）已经使服务提供商无法维持服务质量（QoS）和体验质量（QoE）（Aswale和Ghorpade，2021; Bhat，2018）。因此，分割这样大的视频文件以供共享是由cyberlockers执行的。幸运的是，网络储物柜的碎片化内容为最终用户提供了下载内容的QoS。然而，它损害了流媒体的QoE，因为在流媒体中动态合并大型多媒体文件的片段会对计算基础设施造成负担。不幸的是，通过存储用于流式传输的合并的多媒体文件以及其用于下载的片段来解决这个问题，需要双倍的存储容量来存储实际内容。然而，文件系统设计和开发的进步导致了增强功能的框架的出现文件系统，而不修改其设计和实现。一种这样的流行框架是FUSE（用户空间中的文件存储）（Vangoor等人，2019），它用于开发在用户空间中运行的虚拟文件系统，并且可以在任何https://doi.org/10.1016/j.jksuci.2022.08.0181319-1578/©2022作者。由爱思唯尔公司出版代表沙特国王大学这是一篇基于CC BY-NC-ND许可证的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。制作和主办：Elsevier可在ScienceDirect上获得目录列表沙特国王大学学报杂志首页：www.sciencedirect.comW.A. Bhat沙特国王大学学报8381Fig. 1. 流行的网络储物柜上的内容碎片化（Mahanti等人，2011年）。挂载的文件系统，以预处理和后处理对下面挂载的文件系统的文件系统调用。利用FUSE框架将多媒体文件的片段虚拟地统一到底层挂载的文件系统中，并在统一的虚拟文件上执行流操作，可以在不需要额外存储空间和增加性能开销的情况下解决这个问题此外，所开发的虚拟文件系统可以与所有流行平台上的任何文件系统一起使用，而无需对其设计和实现进行任何修改。在本文中，我们提出了一个基于FUSE框架的文件系统，即fumy，它几乎统一了一个大型多媒体文件的片段，而不会压倒服务提供商的计算基础设施本文讨论了Fumy的设计与实现，并对其在Linux操作系统上的要求和性能开销进行了评估。本文的其余部分组织如下：第2节讨论了与我们相关的工作，第3节讨论了fumy的设计和实现，第4节讨论了所进行的实验及其结果，第5节给出了结论。2. 相关工作过去已经进行了许多研究，以虚拟地统一文件系统资源，从而有效地使用它们。最早的虚拟统一目录的尝试之一包括文件系统，如3D 文件系统（Korn和 Krell， 1990），转换文件系统（TFS ）（Hendricks，1990）和文件系统功能，如Union mounts（Pendry和McKusick，1995）。然而，从头开始开发文件系统是一项繁琐的因此，已经提出了开发可堆叠文件系统以快速且可移植地向现有文件系统添加功能的框架（Heidemann和Popek，1994; Zadok等人，2006年）。已经提出了许多旨在向现有文件系统添加各种功能的可堆 叠 文 件 系 统 （ Joukov 和 Zadok ， 2005; Bhat 和 Quadri ，2012;Bhat，2015）。unionfs是一种可堆叠的文件系统，它位于多个文件系统之上或同一文件系统内的不同目录上，以便将它们逻辑地合并到单个视图中（Wright和Zadok，2004; Wright等人，2006年）。另一种联合文件系统（aufs）也将多个目录联合到一个虚拟文件系统中（Okajima，2006）。此外，多硬盘驱动器磁盘文件系统（mhddfs）将目录或硬盘组合在一起，以创建单个大型虚拟文件系统（Oboukhov，2008）。类似地，OverlayFS将多个不同的底层挂载点合并为一个，从而形成包含所有源的底层文件和子目录的单一目录结构（Szeredi，2010）。上面讨论的文件系统在内核空间中运行虽然文件系统的内核空间实现保证了期望的性能，但是它们的开发除了容易受到可能危及系统的错误的影响之外，还受到内核空间中可用的工具和设施的限制（Vangoor等人， 2017年）。Filesystems in User SpacE（FUSE）是一个文件系统开发框架，它允许文件系统在用户空间中运行时在其他文件系统上分层（Szeredi，2005; Bhat andQuadri，2011）。除了将现有的内核级文件系统移植到用户空间之外，已经提出了许多基于FUSE的文件系统来向用户空间中的现有内核级文件系统添加各种功能（Vangoor等人， 2019年）。unionfs-fuse（Podgorny，2015）是unionfs的FUSE变体，它位于其他文件系统或目录之上，以提供统一的视图。类似地，mergerfs是另一种基于FUSE的文件系统，它简化了跨存储设备的文件存储和管理（Musumeci，2021）。 suvfs是一个基于FUSE的虚拟文件系统，它使 用 虚 拟 统 一 克 服 了 FAT32 文 件 系 统 的 文 件 大 小 限 制 （ Bhat 和Quadri，2013 a）。iStore是基于FUSE的联合文件系统，其通过合并经由高速网络连接的不同地理分布的边缘服务器来提供全局统一命名空间（Khan等人， 2019年）。SDFS是基于FUSE的IoT数据文件系统，可将多个NAS设备集成为一个文件系统，并有效地存储和管理大量传感器数据（Okamoto例如，2020年）。FUSE文件系统的许多其他应用程序，例如作为违规后分析（Bhat和Quadri，2013 b），安全性（Pontes等人，2017）等，但尚未研究大型多媒体文件的有效存储和检索以支持QoS和QoE。3. 模糊3.1. 动机基于FUSE的文件系统能够预处理和后处理定向到它们所在的文件系统的文件系统调用。FUSE框架的这一特性可用于提供大型多媒体文件片段的虚拟统一视图，而不是物理合并它们。这避免了存储容量所需的合并和存储一个大的multime- dia文件的片段，除了显着减少CPU周期和功耗合并他们的飞行。在虚拟文件上执行的操作反映在多媒体文件的适当片段中。3.2. 设计和工作Fumy的主要设计目标是将大型多媒体文件（LMF）的所有分割部分合并为单个虚拟文件（SVF）。然而，碎片的统一观点（即，SVF）不需要存储空间，并且fumy增加的计算开销可以忽略不计。为了实现这个目标，fumy依赖于：a）虚拟统一，b）命名空间操作，c）操作重定向。3.2.1. 虚统一Fumy将LMF的片段的合并视图作为SVF呈现给用户应用。这是通过捕获和处理定向到存储子系统的文件系统调用来实现的。在处理这些系统调用期间，识别与LMF相关联的片段，并且计算和聚合它们的个体大小以向用户应用呈现SVF。与此相关的有两个挑战。首先，需要一个框架来捕获文件系统调用。为此，Fumy使用了FUSE框架。FUSE允许创建虚拟文件系统，这些虚拟文件系统可以层叠在其他已装载文件系统之上。这确保了所有指向下面挂载的文件系统的文件系统操作都通过FUSE文件系统，在FUSE文件系统中，它们可以进行预处理和后处理，如图所示。 二、其次，需要一个策略来识别属于LMF的片段。此外，这些片段的序列应该W.A. Bhat沙特国王大学学报8382←应用程序！基于FUSE的文件系统用户级别内核级虚拟文件交换机（VFS）FUSE内核内核级文件系统存储设备图二、使用FUSE框架拦截文件系统调用合并。为此，fumy使用文件系统名称- pace。使用与LMF名称同名的目录并加上后缀（.fumy）也可以识别文件的名称作为包含其片段的目录。此外，用于统一的片段的顺序通过在目录中添加到片段的数字后缀来识别。作为示例，图3示出了目录名foo.fumy，其通过具有名称foo的fumy作为SVF呈现给用户应用。3.2.2. 命名空间操纵fumy确保文件系统操作无法找到，列表并访问LMF的片段和包含它们的目录。这是通过在FUSE框架中使用名称空间操作来实现的。由于属于LMF的所有片段都可以通过具有特定名称后缀的目录来识别，因此可以限制目录本身在其父目录中列出。这不仅限制了对目录的访问，而且切断了目录中包含的片段的路径。然而，有两个与之相关的挑战：第一，应用程序可能会尝试创建一个与下面挂载的文件系统中包含LMF片段的目录名称完全相同的目录。虽然这样的操作可能被拒绝，但fumy允许它无缝工作的文件系统。但是，在这种情况下，fumy会在名称后面添加一个数字后缀，以便在下面的文件系统中创建它，同时向应用程序提供实际的目录名。作为一个例子，一个名为foo.fumy的LMF目录被表示为foobyfumy，如图4所示。当应用程序尝试创建foo.fumy目录时，在实际文件系统上创建名为foo. fumy. 1的目录，而foo.fumy则显示为图3.第三章。一个包含LMF片段的目录，由fumy作为SVF呈现。到应用程序。同样，当应用程序尝试创建名为foo.fumy.1的目录时，将创建名为foo.fumy.1.1的目录，并将foo.fumy.1呈现给应用程序，依此类推。其次，应用程序可能会尝试创建一个与fumy提供的大文件名称完全相同的目录。虽然可以在fumy下面挂载的文件系统中创建这样的目录，但这会违反名称空间，并在fumy的无缝工作中产生差异。因此，与其他文件系统的情况一样，这样的操作被拒绝。值得一提的是，在这种情况下，文件系统操作返回的错误代码表示具有该名称的文件已经存在，尽管这样的文件或目录在下面挂载的文件系统上不存在。例如，在图4中，唯一不能存在于实际文件系统上的文件或目录是foo，但对fumy没有这样的限制。fumy使用的名称空间操作算法在算法1中列出。算法1：fumy用于列出文件和目录。要求：目录d读取目录1：while目录中的文件do2：d如果目录条目有fumy签名3：如果文件有fumy，则4：d如果条目是目录5：如果文件是目录，则6：d如果目录有扩展名7：如果文件有扩展名，则8：d删除扩展9：DROP_EXTENSION文件10：其他11：d删除签名12：DROP_SIGNATURE文件13：d搜索具有被操作目录名称的条目14：whiledup file indirectory do15：如果dup文件是相同的文件，则16：d17：DROP_FILEdup文件18：如果结束第19章：结束20：如果结束21：其他22：d条目是一个文件23：d如果文件有扩展名24：如果文件有扩展名，则25：d删除扩展26：DROP_EXTENSION文件27：其他28：tmp file文件29：d删除签名30：DROP_SIGNATUREtmp文件31：d搜索可能具有虚拟文件名的条目32：whilesdup fileindirectory do33：如果dup文件是相同的tmp文件，则34：d35：DROP_FILE文件36：如果结束第37章：结束38：如果结束第39章：结束40：如果结束第41章：结束W.A. Bhat沙特国王大学学报8383上述操作场景。fumy使用的操作重定向如图所示。 五、3.3. 执行见图4。 由富米进行的空间操作。3.2.3. 操作重定向Fumy向用户应用程序呈现大文件的片段的虚拟统一这意味着任何指向虚拟文件的文件系统这是通过依赖于操作类型的操作重定向来实现的。对于操纵诸如名称的文件元数据的文件系统操作，操作由fumy重新定向到包含片段的目录，而对许可的修改被定向到目录以及片段两者。然而，读取或写入数据的操作仅针对片段。在这种情况下，fumy根据应用程序提供的偏移量、片段的序列号及其大小来识别片段的文件名，从该文件读取/写入然而，有两个挑战与将读写操作重定向到片段相关联。首先，读取操作可能需要从序列中的一个片段读取一些部分，并且从子片段读取其他部分fumy通过打开已识别的片段并在从FUSE框架返回之前从所有已打开的片段读取所需第二，写入操作可以以这样的方式修改文件，使得文件大小增加或减小，因为数据被添加到一个或多个片段或fumy通过对片段执行单独的操作来解决这个问题，就像它对read所做的那样图五. Operation–redirection procedure of3.3.1. FUSE的动机fumy是使用FUSE框架实现的（Szeredi，2005）。该框架可用于开发成熟的文件系统以及虚拟文件系统。在这两种情况下，文件系统都在用户空间中运行，而不像传统的文件系统在内核空间中运行。因此，FUSE框架简化了文件系统开发，因为用户空间应用程序（即文件系统）可以访问许多开发友好的工具，如C库，这是内核空间模块（如文件系统）开发中缺少的。此外，使用FUSE框架开发的用户空间文件系统不会损害内核的可靠性和稳定性。如果FUSE文件系统遇到灾难性故障，文件系统进程可能会崩溃，此外，基于FUSE框架的用户空间文件系统可以在任何文件系统之上分层，并且可以跨流行平台移植。最后，FUSE文件系统易于部署和管理。3.3.2. 分层基于FUSE框架的虚拟文件系统可以在另一个文件系统之上分层，一个FUSE文件系统，当安装在其他挂载文件系统的挂载点完全覆盖文件系统。这意味着，任何文件系统，TEM操作的目标是挂载文件系统通过FUSE文件系统。FUSE文件系统也可以挂载在一个简单的目录上，只有那些指向子树的文件系统操作才能通过FUSE文件系统。在这两种情况下，对文件系统进行分层可以确保透明性，因为应用程序访问文件系统或目录时不需要更改路径，而且如果不经过FUSE文件系统，就不会留下访问文件系统或目录的路径。3.3.3. 分裂和合并当LMF被复制到文件系统上时，fumy将LMF拆分为相应的片段并按照第3.2.1LMF的最小文件大小和片段的最大文件大小是在fumy挂载时设置然而，分裂LMF和组织片段也可以手动进行。只要遵循组织片段的规范，fumy就可以创建SVF。合并LMF的片段以创建SVF是由fumy为遵循第3.2.1节中描述的规范的底层文件系统中的所有目录执行的。由于拆分也可以手动执行，因此任何与规范的偏差都可能导致合并过程中出现不期望的结果。例如，如果目录名不符合规范，fumy会将目录和其中的片段视为正常的目录和文件。类似地，如果任何片段3.3.4. fumy回调函数fumy在FUSE框架中注册了许多回调函数来拦截指向挂载点的文件系统操作。这些回调函数实现了fumy所要求的虚拟统一、命名空间操作和操作重定向.虚拟 统一 fumy_readdir （ ） 创建 虚拟文 件（ 即， SVF ） ，而asfumy_getattr（）访问目录中片段的属性，并相应地作为一个例子，W.A. Bhat沙特国王大学学报8384fumy_getattr（）聚合所有片段的大小以设置SVF的大小这实现了片段的虚拟统一并将其表示为文件。命名空间操作fumy_readdir（）从目录列表中排除包含LMF片段的目录，并翻译文件和目录的名称，如第3.2.2节所述。除此之外，还有许多其他回调函数执行此操作，例如fumy_mknod（），fumy_unlink（）等。这实现了fumy所需的命名空间操作，以呈现与实际名称不同的文件和目录，更重要的是，呈现不存在的SVF。请注意，创建，transla-tion和排除是在内存中的数据结构中进行的，因此只要fumy被挂载，就会持续存在。操作重定向类似地，fumy_read（）和fumy_write（）函数拦截SVF的写入和读取，因此，将读/写操作重定向到LMF的适当片段。这些函数与其他回调函数一起实现操作重定向。fumy注册的回调函数如清单1清单1：FUSE框架注册的fumyFUSE框架的操作向量由fumy提供的回调函数的地址填充3.3.5. FUSE性能任何基于FUSE框架的文件系统都会遇到性能问题。FUSE文件系统作为用户空间中的进程运行，并服务于从用户空间中的应用程序进程接收的请求（通过内核空间中的FUSE内核模块这种复杂的请求和回复过程增加了FUSE文件系统的性能成本，fumy也不例外。首先，从应用到fumy的请求需要处理上下文切换到fumy以履行请求，并且反之亦然以消费回复，如图6所示总共两个上下文切换。第二，由于所有的通信都是通过内核空间进行的，因此如图7所示，应用程序请求的文件系统操作至少会导致四个操作模式切换。最后，出于与上述相同的原因，由FUSE文件系统执行至少两个存储器拷贝，如图8所示。然而，已经进行了许多研究来克服FUSE文件系统所面临的性能问题。 这些进展，如拼接，可在本研究中使用的最新版本的FUSE开发包（fuse-3.10.5）中获得。4. 实验4.1. 目标实验的主要目的是验证烟气的工作原理和评价烟气的性能。为了实现这一目标，我们首先评估了所有扩展文件系统（ext2，ext3和ext4）使用各种配置的基准测试读取LMF的性能。然后，我们将LMF拆分为它们的片段，并评估扩展的文件系统，在它们上面分层，以评估它们使用相同工作负载读取SVF的性能。这不仅验证了工作，也评价了fumy的性能。4.2. 基准程序这些实验使用基准测试来测试扩展的文件系统，在这些文件系统上分层使用和不使用fumy。该基准测试采用了6种片段大小配置，8种访问模式，以及ext 2、ext 3和ext4文件系统的2种配置-总共产生288轮。在每轮中，基准读取10个文件，每个文件的大小为16 GiB（即每轮读取160 GiB）。见图6。 在fumy中请求-应答调用期间的上下文切换。见图7。 模式开关在请求-应答调用在烟雾。在每一轮中，所有的SVF都由底层文件系统上它们各自的片段的6种不同大小之一表示。这些片段大小包括128 MiB、256 MiB、512MiB、1 GiB、2 GB和4 GB。作为示例，在第1轮中，所有10个文件由它们各自的片段组成，每个片段的大小为128 MiB。由于每个虚拟文件是16 GiB，因此每个这样的文件在这一轮中具有128个片段，每个片段的大小为128 MiB此外，在所有轮次中，所有文件都使用8种访问模式之一来读取。这些访问模式代表了大型多媒体文件读取整个文件的各种工作负载。在所有访问模式中，每次访问读取的数据大小（即一个块）至少是该轮的片段大小的50%。作为示例，在上述轮1中，在一次访问中读取64 MiB大小的数据块，因为该轮的片段大小是128 MiB。由于这个块可以完全从一个片段或两个连续的片段中读取，因此基准测试支持两种主要的访问模式a) 块内根据下一个块是靠近还是远离当前读取的块，这些访问模式可以是靠近或远离。在within-near和span-near中，读取的两个连续块被一个块分隔，即，顺序地读取文件中的交替块。然而，在读取最后一个块之后，基准可以回到开始以类似的方式读取遗漏的块（即，读取交替遗漏的块）。另一方面，基准可以扭转阅读方向，见图8。 在fumy中请求-应答调用期间的内存复制。W.A. Bhat沙特国王大学学报8385从末尾到开头来读取遗漏的替换块。相应地，我们有内近周期（WNC）和跨度近周期（SNC）的访问模式为前一种情况下，和内近nocycle（WNN）和跨度近nocycle（SNN）的访问模式为后一种情况。类似地，在within-far和span-far中，读取的两个连续块被变化数量的块（即，within-far变化和span-far变化）或固定数量的块（总块的一半）（即，within-far固定和span-far固定）分开。在远变内（WFV）和跨度远变（SFV）模式中，在读取第一个块之后，读取最后一个块然后读取第二个块，接着读取倒数第二个块。这个过程一直持续到最后两个连续读取的块是中间的两个连续块。这两种模式之间的唯一区别是，块读取要么在同一个片段内，要么跨越两个连续的片段。相比之下，在远内固定（WFF）和跨度远固定（SFF）中，连续读取的两个块总是彼此相距一半，即，在读取第一块之后，读取中间的块在此之后，读取第二个块，然后是中间块旁边的块。该过程继续，直到读取的最后两个块是刚好在中间块和最后块之前的块。同样，这两种模式之间的区别在于，块读取要么在同一片段内，要么跨越连续的片段。 图图9示出了当块大小被设置为片段大小的50%时用于WNC、WNN、WFF和WFV访问模式的过程。如果块大小为90%，则该过程表示SNC、SNN、SFF和SFV。4.3. 设置实 验 在 具 有 Intel® CoreTM i7-3770 CPU@3.40 GHz 的 HPCompaq Elite 8300 MT上进行，该CPU具有256 KiB L1高速缓存、1 MiB L2高速缓存和8 MiB L3高速缓存。安装的系统内存是8GB DDR3，频率为1600 MHz。实验中使用的硬盘是具有1 TB容量和7200 rpm转速的3.5英寸SATA驱动器（型号ST 1000 DM 003 -1CH 162）。该磁盘被分区为一个20 GB的分区，其中Fedora Core34操作系统（内核版本5.14.13x86_64）已安装。创建了另一个500GB的分区来装载文件系统。所有文件系统都安装在同一个500 GB分区上。这样做是为了减少ZCAV对文件系统性能的影响，当文件系统安装在不同的分区上时，这反映在基准测试结果中。此外，文件系统的大小保持最低限度，以实现相同的寻求和旋转延迟的所有部门的卷，通过限制他们的最低要求数量的柱面。此外，所有文件系统都是使用默认参数新建的。此外，实验是在运行级别1的Linux上进行的，以减少其他应用程序和守护进程的随机影响。此外，基准测试是使用bash4.1.7（1）版作为shell脚本实现的。4.4. 结果我们通过计算并比较每轮中每个SVF读取的校验和与其相应的分段LMF的校验和来验证fumy的工作每个文件的每一轮检查和比较的结果都没有显示出任何差异。4.4.1. ext2文件系统对于ext2文件系统，对于读取的块完全在单个片段内的工作负载，ext2文件的性能系统与ext2文件系统相比，fumy分层在它上面，如图所示。 10个。结果表明，在每个文件系统内的访问模式之间的性能没有太大的差异然而，在ext 2-with-fumy和ext 2文件系统之间，当片段大小为128 MiB时，工作负载的访问模式之间存在事实上，当碎片大小大于2 GiB时，ext 2-with-fumy在WFF和WFV工作负载上优于ext 2文件系统此外，两个文件系统之间的相应访问模式之间的性能差距开始积极后退的片段大小raeches 512 MiB。类似地，对于其中块跨越两个碎片的工作负载，ext2文件系统与在其上分层的fumy的ext2文件系统相比的性能如图所示。 十一岁与早期的观察相反，当碎片大小大于256 MiB且小于2 GiB时，每个文件系统内的访问模式之间的性能存在显著差异然而，在ext 2-with-fumy和ext 2文件系统之间，工作负载的访问模式之间存在明显的性能差距，当片段大小达到512 MiB时，这种差距就消失了。4.4.2. ext3文件系统对于ext3文件系统，对于其中读取的块完全在单个片段内的工作负载，ext3文件系统的性能与在其上分层的fumy的ext3文件系统相比如图12所示。对于所有的访问模式，ext3文件系统的性能没有显著差异。同样，对于ext 3-with-fumy，WNC和WFV访问模式的性能没有显著差异。然而，WNN和WFF访问模式在ext 3-with-fumy上的性能很大程度上偏离了文件系统的其他模式的性能。事实上，对于256 MiB和2 GiB的片段大小，ext 3-fumy上的WNN和WFF工作负载在所有访问模式下都优于ext 3文件除此之外，所有访问模式在ext 3文件系统上的性能都优于它们在ext 3-with-fumy上的性能。类似地，对于块跨越两个片段的工作负载，ext3文件系统与fumy分层的ext3文件系统的性能比较如图所示。 13岁从结果可以看出，对于128 MiB的碎片大小，ext3文件系统中所有访问模式的性能趋于（几乎）相同，并且随着碎片大小的增加，访问模式之间的性能差距也会增加，在碎片大小为1 GiB时达到峰值随着片段大小的进一步增加，每碱基间隔开始减小，对于4 GiB的片段大小，它们的性能没有差异。对于ext 3-with-fumy可以进行类似的观察。然而，在ext 3-with- fumy和ext 3文件系统之间，对于所有相应的访问模式，都存在一个小而固定的性能差距。对于128 MiB和256 MiB片段大小，该间隙稍宽在512 MiB片段大小的情况下，该间隙显著减小，并且对于所有更高的片段大小保持固定此外，在ext 3-with-fumy和ext 3文件系统之间，访问模式的性能没有明显差异例如，对于512 MiB的片段大小，ext 3-with- fumy上的SNN性能优于ext 3文件系统上的SFF和SFV类似地，对于1GiB的片段大小，ext 3-with-fumy上的SNN工作负载优于ext 3文件系统上的SNC、SFF和SFV工作负载。此外，对于1 GiB的片段大小， ext 3-with-fumy上的SNC工作负载优于ext 3文件系统上的SFF和SFV4.4.3. ext4文件系统对于ext4文件系统，对于读取的块完全在单个片段内的工作负载，ext4文件的性能W.A. Bhat沙特国王大学学报8386见图9。 用于评估烟雾的基准程序。W.A. Bhat沙特国王大学学报8387见图10。 ext 2 vs ext 2-with-fumy见图12。 ext 3 vs ext 3-with-fumy见图11。 ext 2 vs ext 2-with-fumy系统与ext4文件系统相比，fumy分层在它上面，如图所示。 十四岁从结果中可以明显看出，除了128 MiB和512 MiB之外，ext4文件系统中所有访问模式的性能对于所有片段大小都是相同的ext4-with- fumy上的访问模式也具有相同的性能，除了具有256 MiB片段大小的WFF、具有512 MiB片段大小的WNC和具有2 GiB片段大小的WFV之外。此外，ext4-with-fumy和ext4文件系统之间事实上，对于256 MiB和512 MiB的片段大小，ext4-with-fumy 上的WFF和WNC的性能然而，在ext4-with-fumy和ext4文件系统之间，对于128 MiB片段大小的所有相应访问模式，存在很大的每字节差距然而，随着片段大小的增加，该间隙减小。具体而言，在片段大小为1 GiB的情况下，该间隙变得不那么重要，并且对于较大的片段大小保持固定。同样，对于块跨越两个碎片的工作负载，ext4文件系统的性能与ext4文件系统相比，图十三. ext 3 vs ext 3-with-fumy系统与烟雾层在它上面显示在图。 十五岁从结果中可以明显看出，对于128 MiB的碎片大小，ext4文件系统中访问模式的性能趋于相同，并且随着碎片大小的增加，访问模式之间的性能差距随着片段大小的进一步增加，性能差距开始减小，对于4 GiB的片段大小，性能没有差异对于ext4-with-fumy可以进行类似的观察。然而，在ext4-with- fumy和ext4文件系统之间，对于所有相应的访问模式，都存在一个小而固定的性能差距对于128 MiB片段大小，该间隙稍宽与256 MiB片段大小，该间隙显著减小，并且对于所有更高的片段大小保持固定此外，ext4-with-fumy和ext4文件系统之间的性能没有明显差异。例如，当片段大小较大W.A. Bhat沙特国王大学学报8388表1使用fumy的扩展文件系统的性能损失/增益。见图14。 ext4 vs ext4-with-fumy小于256 MiB和小于2 GiB。同样，ext4上的性能with-fumy的性能优于SFF和SFV访问模式，ext4文件系统上的扩展，当片段大小大于256兆 然而，对于所有相应的访问模式，在ext4-with-fumy和ext4文件系统之间，对于所有大于512 MiB的片段大小，性能差距可以4.5. 讨论4.5.1. 分析我们计算了扩展文件系统在基准测试的所有轮次中所产生的性能损失/增益表1显示了当fumy覆盖在扩展文件系统上时，对于所有访问模式和碎片大小，扩展文件系统的性能损失/增益百分比。结果清楚地表明，128 MiB的碎片大小不适用于所有扩展文件系统上的所有工作负载;特别是，图15. ext4 vs ext4-with-fumyext2和ext3文件系统，因为性能损失至少高于5%（在表1中以红色突出显示）。对于ext2文件系统，对于256 MiB的片段大小也可以得出相同的结论。幸运的是，除了这些片段大小之外，很少有片段大小和工作负载组合会导致如此严重的性能损失（表1中未突出显示）。事实上，对于碎片大小为512 MiB或更高的所有工作负载，ext4文件系统的性能损失低于1%， ext3文件系统为2%此外，有许多工作负载和片段大小的组合，当fumy在它们上面分层时，扩展文件系统会带来性能增益而不是损失（在表1中以蓝色和绿色突出显示）。与ext2文件系统相比，这些性能增益在ext4和ext3文件系统中出现得更频繁还可以发现一些巨大的性能提升（在表1中以绿色突出显示），主要是由ext2和ext3文件系统引起的。此外，由于扩展文件系统由于fumy而引起的每次命中（或增益）在片段大小和工作负载上是不一致的，因此针对特定工作负载为特定文件系统选择特定片段大小可以在期望的程度上避免性能损失。4.5.2. 解释我们推断a）当片段大小为512 MiB或更高时，fumy对扩展文件系统的性能影响可以忽略不计b) Fumy增强了特定工作负载和片段大小的扩展文件系统的性能，c）由ext2和ext3文件系统引起的性能增益与可能不期望的巨大片段大小相关联，d）Fumy对ext4文件系统施加最少的额外负担，其次是ext3和ext2文件系统，e）128MiB和256MiB的片段大小导致具有Fumy的扩展文件系统的显著性能开销，以及f）选择工作负载和文件系统特定的片段大小可以避免由于Fumy而导致的显著性能损失。4.5.3. 建议根据调查结果及其分析和解释，本研究建议服务提供者可以：W.A. Bhat沙特国王大学学报8389在所有扩展文件系统中，使用ext4文件系统，使用fumy对碎片文件进行虚拟统一，以确保性能开销保持在最低限度。将所有文件系统的碎片大小设置为512 MiB，以保持最小的性能开销，同时为系统进行通用配置。出于性能原因，请避免使用128 MiB和256 MiB的片段大小。为每个文件系统配置特定于工作负载的片段大小，以实现最佳性能。5. 结论在本文中，我们提出了使用基于FUSE框架的文件系统（即fumy）来虚拟地统一大型多媒体文件的碎片的想法，以便于服务提供商有效地使用存储容量，以支持下载中的QoS，同时维持流传输中的QoE。我们讨论了fumy的设计和实现，并描述了实验设置，以验证fumy的工作和评估的性能时，分层扩展文件系统。我们的研究结果表明，fumy不仅有利于服务提供商有效地存储大文件作为大量的小文件，但也这样做，最小的perfor- mance开销的工作负载和碎片大小的扩展文件系统的组合。在某些情况下，fumy甚至增强了扩展文件系统的性能。作为未来的工作，我们建议进行其他文件系统上的性能评估。竞争利益作者声明，他们没有已知的竞争性财务利益或个人关系，可能会影响本文报告的工作。确认作者感谢沙特阿拉伯麦地那伊斯兰大学科学研究主任在出版后支持赠款下支持这项引用阿加瓦尔河，维尔玛，J.，Siwach，M.，2021. Hadoop中的小文件J. 沙特国王大学Comput.INF. Sci.Aswale，S.，Ghorpade，V.R.，2021.无线多媒体传感器网络中基于三角形链路质量度量的最小路径间干扰地理多径路由。J.沙特国王大学- Comput.信息科学33（1），33-44. Bhat，W.A.，2015年。在透明的每文件安全擦除扩展中实现高效清除。云计算安全注意事项研究手册计算的 IGI Global，345-357.Bhat，W.A.，2018年弥合大数据存储中的数据容量差距未来一代Comput.系统87，538-548。Bhat，W.A.，2018年大数据存储中的数据容量缺口是不可避免的 Computer 51（9），54-62.Bhat，W.A.，Quadri，S.，2011.开源代码并不总是有帮助：文件系统开发案例。趋势信息管理。7（2）.Bhat，W.，Quadri，S.，2012. Restfs：使用可靠&高效的可堆叠文件系统保护数据删除。IEEE第10届应用机器智能与信息学国际研讨会（SAMI）IEEE 2012，457-462.Bhat，W.A.，Quadri，S.，2013年a。suvfs：用户空间中支持大文件的虚拟文件系统。2013年IEEE大数据国际会议IEEE，pp。 7比11Bhat，W.A.，Quadri，S.，2013.海报：沃森博士提供数据用于违约后分析。2013年ACMSIGSAC计算机通信安全会议论文集。pp. 1445-1448年。陈，M.，龚，M.，那霸，