CN107862064A - 一个基于nvm的高性能、可扩展的轻量级文件*** - Google Patents
一个基于nvm的高性能、可扩展的轻量级文件*** Download PDFInfo
- Publication number
- CN107862064A CN107862064A CN201711133827.XA CN201711133827A CN107862064A CN 107862064 A CN107862064 A CN 107862064A CN 201711133827 A CN201711133827 A CN 201711133827A CN 107862064 A CN107862064 A CN 107862064A
- Authority
- CN
- China
- Prior art keywords
- file
- data
- file system
- nvm
- section
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/13—File access structures, e.g. distributed indices
- G06F16/134—Distributed indices
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提出一个基于NVM的高性能、可扩展的轻量级文件***,包括:超级块,索引节点表,哈希表,区段表,元数据日志,数据日志,位图和文件数据空间;索引节点表中存储索引节点,每个节点存储必要的元数据信息;区段表中存储区段,每个区段存储一段以字节单位组织的连续区域信息;文件***命名层由所述全局哈希表组织,其每个哈希桶是一个链接了具有相同哈希值的节点的链表;每个文件的数据由基于区段的文件B+树管理,各区段作为文件树的叶节点表示对应的文件数据片段;元数据日志和所述数据日志均包含多个日志文件;位图表示文件***中每个数据块的使用情况;文件数据空间存储文件数据,以4KB大小的块为单位进行管理。
Description
技术领域
本发明涉及数据存储,尤其涉及一个基于NVM的高性能、可扩展的轻量级文件***。
背景技术
新型非易失存储NVMs,如Phase change memory(PCM)、Spin Transfer TorqueRAM(STT-RAM),读写速度接近内存、能和CPU直接通信进行字节寻址访问、具有非易失性即断电后数据不会消失的特点。这些非易失存储技术的出现将会彻底改变现有的存储***模式,并且为数据访问提供高度的并行性和极低的延迟(纳秒级)。
虽然非易失存储NVMs性能优越,但也正是因为它读写速度快、非易失性等特点为其上文件***的设计带来了挑战,导致文件***开销凸显,并且失去了数据一致性的保证。为了能够充分利用NVMs所提供的高性能,现有基于NVMs的文件***改变了传统基于磁盘的文件***的设计来利用NVMs的特性,如能与CPU直接通信、可字节寻址等。
现有技术中较为优秀的基于NVM的文件***,如图1所示,磁盘文件***需要通过DRAM页缓存和存储设备进行数据传输;由于非易失存储NVM是字节寻址方式,所以其上文件***可以使用一种DAX或者XIP技术直接从NVM上读写数据,无需再进行NVM和DRAM页缓存之间的数据拷贝,从而提升性能。目前市场上基于NVM的文件***都是此类DAX文件***,本发明的文件***也采用了这种模式。
(1)BPFS
BPFS提出一种short-circuit shadow paging技术实现数据细粒度的更改,减少了传统技术带来的级联写入时复制(Copy-On-Write)更新整棵文件树的多余开销;提出一种提交策略将顺序性与持久性解耦合,以缓解刷新缓存的开销。
(2)PMFS
PMFS跳过块层和页缓存,采用如图1所示的DAX技术提高性能,采用原子的in-place更新和细粒度日志机制保证元数据更新的原子性,采用undo日志和写入时复制(Copy-On-Write)混合方式保证数据的一致性。
(3)NOVA
NOVA采用日志结构的方式保证操作原子性和数据一致性,在内存中创建radix树来检索日志,通过设置每个节点对应一个日志来保证高并发性,对文件数据采用写入时复制(Copy-On-Write)和日志方式保证一致性,提出了原子的文件映射进内存机制。
(4)SoupFS
SoupFS将软升级方法用于文件***,应用延迟持久化方法消除文件******调用关键路径中的同步缓存刷新,提出了基于指针的双观测机制,共享大多数的数据结构,但是在不同的视图中使用不同的指针,从而保证在不同步刷新缓存情况下的正确性和一致性。
然而在现有技术中,即便基于NVM的文件***针对NVM做了优化,仍旧不能充分利用NVM的特点而提供高性能的存储。现有技术中存在的问题有以下三点。
(1)虚拟文件***VFS在NVM上带来了很多不必要的开销和扩展瓶颈
现有基于NVM的文件***都是在传统的I/O堆栈体系结构限制下提升底层文件***性能,仍需要传统的VFS层提供层次化命名和访问保护。然而,传统的VFS层是基于传统的读写缓慢的磁盘等块设备设计,为存储在磁盘上的文件***对象提供内存缓存,其在高性能的NVM上的已无必要。VFS在传统I/O堆栈体系结构中的作用是为底层文件***提供内存缓存,当在内存中没有查找到目标对象时,就会引发在底层文件***中的额外查找,例如创建新文件时的路径解析过程。由于磁盘上的查找速度较慢,双重查找问题对磁盘文件***的性能影响不大。但是在访问速度接近DRAM的NVM上,在VFS上的查找开销就变得显著。分配、初始化、释放这些内存缓存结构也带来了不必要的开销。此外,虚拟文件***VFS采用了一些全局锁来保护并发的***和删除,带来了多核***上的并发瓶颈。
(2)采用传统写入时复制Copy-On-Write和日志方式提供数据一致性带来多余拷贝开销
现有技术的基于NVM的文件***通常采用写入时复制Copy-On-Write(COW)和日志机制来提供数据一致性保证,即以块为单位对文件数据进行索引和修改,然而对于非块对齐的修改文件数据情况,采用写入时复制COW机制就需要将涉及的数据块中不需要覆盖写的部分拷贝到新申请的空间,再写下新的数据。NVM可以直接字节寻址访问,就可以避免拷贝不需要覆盖写的数据所引起的额外开销。对于日志,现有技术处理的方式需要写两次:一次写到日志,一次写到文件***,并且也是以块为粒度进行更新的,现有基于NVM的文件***采用了细粒度的日志来消除这些不必要的开销。而细粒度的日志只记录修改的元数据信息,但是他们仍需要在修改NVM上的元数据信息之前将所有元数据信息记录在日志,日志记录的开销仍会随着要修改的元数据大小增加而增加。
(3实现atomic-mmap存在冗余拷贝
可直接和CPU通信进行字节寻址的NVM使得DAX-mmap技术成为现实,应用程序将NVM上的物理地址映射到用户地址空间,通过load/store指令直接访问NVM,跳过了页缓存。但是,当***崩溃时,包括传统文件***在内的大多数文件***都无法保证内存映射的数据一致性。NOVA通过采用COW机制修改文件数据和原子的同步共享内存区的文件数据到存储设备atomic-msync机制进行同步,实现了原子文件映射进内存(atomic-mmap)。但是,NOVA不能识别脏页,在同步时,会将所有内存映射的数据都回写到NVM,即便这些数据只是被读取而没有被修改。
发明内容
为了更好地解决上述问题,本发明提出了一个基于NVM的高性能、可扩展的轻量级文件***PLFS,在所述文件***PLFS中,将传统虚拟文件***VFS和底层文件***命名空间整合,在基于NVM的I/O堆栈体系结构下重新设计了轻量级的命名层,采用以字节为单位的细粒度的索引树实现了Non-Copy-On-Write机制,消除了传统Copy-On-Write为保证数据一致性带来的多余拷贝,尽可能的降低日志开销,提出了轻量级的atomic-mmap,通过标记脏页消除不必要的数据回写,提高执行文件操作的速度,在保证一致性的同时也保证了文件***的高效和可扩展性,从而提升***性能。
附图说明
图1为现有技术中基于NVM的文件***结构;
图2为本发明的文件***数据结构的整体分布图;
图3为本发明一实施例的哈希桶和元数据日志的映射示意图;
图4为本发明一实施例的写文件过程。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。此外,下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
本发明提出一个基于NVM的高性能、可扩展的轻量级文件***PLFS,其是在多核***上高度可扩展的、高效的、具有强一致性保证的文件***。本发明的文件***PLFS在NVM上进行整体布局,将整个NVM空间分成八个部分,如图2所示为本发明结构的整体分布图,包括:超级块(superblock),索引节点表(pinode table),哈希表(hash table),区段表(extent table),元数据日志(metadata journal),数据日志(data journal),位图(bitmap)和文件数据空间,所述文件数据空间存储文件数据,以4KB大小的块为单位进行管理。
在本发明中,文件***实体(如文件或目录)的元数据信息存储在索引节点pinode中;命名层由一个全局的哈希表组织,用于管理索引节点pinode;每个文件的数据由基于区段extent的B+树管理,每个B+树叶节点指向的区段extent表示由字节单位组织的文件数据片段(file data piece)的连续区域;超级块包含了整个文件***的信息;NVM上的整个文件数据空间以块为单位管理,为了节省空间,本发明的文件***PLFS使用位图表示每个数据块的使用情况。
本发明的文件***PLFS在NVM上用一块连续的区域,即索引节点表pinode table,存储索引节点pinode,并在内存中用每CPU的链表管理这些pinode的申请和释放。每个pinode占128字节空间,存储了必要的元数据信息,如文件名、文件大小、文件树第一个区段位置等,文件***PLFS通过给定的pinode编号对其寻址访问。所有文件***实体由一个全局哈希表组织,哈希表中每一个哈希桶是一个链接了具有相同哈希值的pinode的链表,每个哈希桶由一个自旋锁(spinlock)锁进行保护。为了快速检索,文件***PLFS在内存中也保留了一个和NVM上一致的完整的哈希表。
本发明的文件***PLFS在NVM上用一块连续的区域,即区段表(extent table)存储区段extent,并在内存中用每CPU的链表管理这些extent的申请和释放。区别于其他文件***采用的以块为单位的extent,文件***PLFS采用的是以字节为单位的extent。每个extent记录了对应的文件数据片段的在文件中的起始偏移和这段连续空间的字节数。相应的,文件树也是以字节为单位进行索引的B+树,索引键值根据每个文件数据片段的起始偏移生成。文件***PLFS对每个文件都在内存中建立了完整的B+树进行索引,在NVM上只记录这个文件树叶节点指向的extent,并将所有extent链接起来进行内存文件树的重建,在对应的pinode中记录了第一个extent的位置。
本发明的文件***PLFS采用包含多个日志文件的元数据日志和数据日志分别为目录操作和文件操作提供原子性保证。每个日志文件都是NVM上一段连续的区域,在起始位置记录了日志头和日志尾,在末尾位置记录了下一个日志文件的地址。为了保证并发性,文件***PLFS采用分布式的日志方式,将哈希表和元数据日志映射,每一个哈希桶根据它的哈希值对元数据日志文件数取模分配其对应的日志文件。
如图3所示为一实施例的哈希桶和元数据日志的映射示意图,每个pinode具有各自的数据日志,在同步文件数据时申请日志文件,当一个日志文件写满时申请新的日志文件并将其链接到最后一个日志尾部。
本发明的文件***PLFS的核心组成部分包括一个用于命名空间管理的轻量级命名层,用于每个文件数据管理的字节粒度索引的文件树,轻量级的可扩展的用于保证一致性的元数据和数据日志以及轻量级的原子文件映射***(atomic-mmap)调用的实现。
本发明的文件***PLFS将传统的虚拟文件***VFS和底层文件***的命名空间整合成一个适用于NVM的轻量级命名层,提供和虚拟文件***类似的命名和权限检查功能。具体来说,本发明的文件***PLFS将虚拟文件***虚拟文件***中的多个关键数据结构,如节点inode、目录项dentry,压缩成一个索引节点pinode结构,采用一个全局的哈希表管理整个命名空间。文件***PLFS采用双向链表组织目录结构,在表示目录的索引节点pinode中包含一个指向第一个子目录的指针,所有的子目录都由双向链表链接起来。对于一个给定的目录,PLFS的轻量级命名层就可以遍历其所有的子目录,完成Linux中类似于ls的操作。
本发明的以open操作的实施例,以此说明本发明的文件***PLFS如何在命名层进行路径解析,以查找和路径名查找每个部分相对应的索引节点pinode。路径解析就是遍历命名空间树的过程,解析由”/”分隔开的各个路径名组成部分,查找每个部分对应的pinode,从而找到最后一个目标节点。首先,从路径名的第一部分开始,通常第一部分是根目录(root)或者当前目录(cwd),具有已知的pinode;然后根据下一部分路径名和当前pinode的编号计算哈希值,在其对应的哈希桶中遍历,找到这个pinode对应于路径名下一部分的子目录pinode;迭代进行上一步骤,直到找到最后节点的父目录pinode,完成路径解析过程。
为了支持并发操作,本发明的文件***PLFS的命名层为每个哈希桶设置一个锁来保护哈希表中并发的***和删除操作。由于哈希表中对索引节点pinode的查找远比***和删除操作频繁,所以命名层使用RCU锁来保护每个桶的查找过程,使得所有的读在任何时候都是并发的,只有***和删除才由自旋锁(spinlock)保证正确性。另外,不同的哈希桶之间的***和删除也是并发的,因为每个哈希桶的修改由单独的锁保护即可。
对于同时涉及多个桶修改的操作如重命名,命名层为每个哈希桶设置顺序锁(sequence lock)保证操作的原子性和并发性。由于重命名操作修改了pinode中存储的文件名,相应的哈希值就会改变,就需要根据新的哈希值将pinode从源哈希桶中删除,再***到新的哈希桶中。由于RCU锁保护的查找过程可以在任何时候执行都没有竞争,那么当删除操作执行完,pinode还没有***到新的哈希桶中时,无论用旧名字还是新名字都将无法查找到这个pinode。因此命名层为每个桶设置sequence lock,在重命名更新操作没有完成的情况下,查找操作会不断重复,直到相应桶的修改完成,从而避免上述情况的发生。
本发明的文件***PLFS采用以字节粒度索引的B+树来管理每个文件的数据,从而避免COW带来的多余拷贝开销。文件树的每个叶子节点表示一个有连续空间的文件数据片段,用字节粒度的区段管理,记录了这个数据片段在文件中的起始偏移和连续的字节数。相应的,文件树的索引键值由这些数据片段的起始偏移构成。
下面以写操作为例说明本发明的文件***PLFS是如何执行写文件的。如图4所示为一实施例的写文件过程,首先文件***PLFS根据写操作给定的起始位置查找B+树中对应的区段extent1;由于写数据占三个块大小,所以申请三个块大小的新数据空间,用起始偏移对每个块所占字节(4KB)取模,计算在NVM上的写起始位置,写下新数据,并用新的extent2记录这个数据片段的信息;由于是覆盖写操作,文件***PLFS将原有的extent1拆分,用新的extent1记录没有被覆盖写的前面部分,用extent3记录没有被覆盖写的后面部分;最后将这三个新的区段***到文件树中,完成write操作。综上,可以看到,文件***PLFS采用字节粒度管理文件数据片段,完全避免了对没有覆盖写部分到新空间的拷贝工作,而是保留其在NVM上的位置,只是由新的extent来管理,我们称这种技术为Non-Copy-On-Write(NCOW)。
本发明的文件***PLFS采用分布式的元数据日志来保证添加、删除、重命名等操作的原子性。当在内存上的哈希桶中***或删除一个索引节点pinode时,元数据日志需要将这个pinode的更新操作记录到日志文件中,涉及pinode本身包含信息的修改,以及它所在哈希桶和目录双向链表的维护。为了减少日志开销,文件***PLFS提出了一种写入时重定向(Redirect-On-Write,ROW)机制,在NVM上申请新的pinode并初始化为更新的信息,在日志中只记录这个pinode的地址,而不需要记录更新的信息。为了维护哈希桶和目录双向链表,还要记录pinode在这两个链表中front和next域指针。由于next域指针已经记录在pinode中,所以元数据日志只需要记录front域指针。
本发明的文件***PLFS关于文件修改的同步过程在同步内存中所有修改的文件数据到存储设备操作fsync中执行,当文件树***、删除或者更新叶子节点时,数据日志需要将更新的区段extent记录到日志文件中,涉及extent本身包含信息的修改,以及该文件在NVM上所有extent链表的维护。同样采用ROW的机制记录每个文件中extent的更新,先在NVM上申请新的extent并初始化为更新的信息,然后在数据日志中记录新extent的地址。由于发生故障后进行***恢复时要根据每个文件数据片段所占用空间的大小的变化来更新位图,所以还需要在日志中记录旧的extent的地址。为了维护NVM上extent链表,需要记录其的左右邻接extent地址。由于extent中已经记录了front和next域指针,所以无需在数据日志中记录。
为了保证操作的原子性,每一个日志文件都在文件头位置包含了head和tail指针,分别指向一个更新操作涉及所有日志项的起始记录位置和终止记录位置。添加日志项时,首先读取head指针,从起始位置开始添加;当一个文件操作涉及的日志项全部添加完毕以后,再更新tail指针指向日志尾。全部日志项持久化以后,再维护哈希桶、目录链表、文件区段extent链表等,修改NVM上涉及的邻接点(front和next域所指向的节点)的front和next域指针,以及位图等。当NVM上所有信息全部持久化更新以后,文件***PLFS会修改head指针,使其指向tail所指位置,即完成清理日志的工作。
当发生***故障进行恢复时,如果head和tail指向相同的区域,要么更新操作已经全部持久化,日志被清理,无需恢复;要么该操作的日志项没有添加完整,由于本发明的文件***PLFS采用redo日志,上一一致性状态在NVM上仍然保持,也不需要进行恢复操作。只有head和tail指向不同区域,说明日志项已全部添加,根据日志中记录的pinode和extent地址找到NVM相应的对象,根据其内容进行NVM上链表的维护及位图的更新等操作。最后再根据NVM上恢复后的保持一致性状态的文件***信息,重建内存上的哈希表和文件树。
本发明的文件***PLFS为了避免回写未修改的内存映射数据页,追踪了操作***缺页中断过程,在发生缺页中断时,记录了脏页信息。当同步共享内存区的文件数据到存储设备***调用进行同步操作时,其只需要像写文件操作(write)及同步内存中所有修改的文件数据到存储设备操作(fsync)一样原子的回写脏页,并将这些脏页的标志位清空,如果下次调用msync前没有再修改这个页,将不用再次回写。
本发明的文件***PLFS基于Linux内核,由于文件***PLFS的命名层跳过了传统的VFS层,在每个***调用起始处做拦截判断是否为PLFS下的文件操作,如果是,则进入文件***PLFS的接口中处理;否则,仍进入原有的虚拟文件***VFS层进行处理。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (8)
1.一个基于NVM的高性能、可扩展的轻量级文件***,包括:超级块,索引节点表,哈希表,区段表,元数据日志,数据日志,位图和文件数据空间;所述超级块包含了整个文件***的信息;所述索引节点表中存储索引节点,每个所述索引节点存储了必要的元数据信息;所述哈希表用于组织文件***命名层,其每一个哈希桶是一个链接了具有相同哈希值的索引节点的链表;所述区段表存储区段,每个所述区段存储一段以字节单位组织的连续区域信息;每个文件的数据由基于所述区段表的文件树管理;所述元数据日志和所述数据日志均包含多个日志文件,为目录操作和文件操作提供原子性保证;所述位图表示文件***中每个数据块的使用情况;所述文件数据空间存储文件数据,以4KB大小的块为单位进行管理。
2.如权利要求1所述的文件***,其特征在于,所述索引节点表为非易失存储NVM上的一块连续的区域存储所述索引节点,由内存中的每CPU链表管理所述索引节点的申请和释放,每个所述索引节点占128字节空间,存储了必要的文件元数据信息,所述元数据信息包括文件名、文件大小、文件树第一个叶节点位置等,文件***可以通过给定的索引节点编号对所述索引节点进行寻址访问,所述哈希表为一个全局结构,用于管理文件***命名空间,其每一个哈希桶是一个链接了具有相同哈希值的索引结点的链表;所述区段表为NVM上的一块连续的区域存储所述区段,由内存中的每CPU链表管理所述区段的申请和释放,所述区段以字节为单位记录对应的文件数据片段在文件中的起始偏移和这段连续空间的字节数,所述文件树是以字节单位键值进行索引的B+树,索引键值根据每个文件数据片段的起始偏移生成,每个叶节点均有指针指向键值对应的区段,文件***中的每个文件都在内存中建立了完整的B+树进行索引,NVM只记录所述文件树的叶节点(区段),所有区段链接起来以便进行内存文件树的重建,在该文件的索引节点中记录第一个区段的位置。
3.如权利要求2所述的文件***,其特征在于,所述文件***将哈希表和元数据日志映射,每一个哈希桶根据其哈希值对元数据日志文件数取模分配其对应的元数据日志文件;每个所述索引节点具有各自的数据日志,在同步文件数据时申请日志文件,当一个日志文件写满时申请新的日志文件并将其链接到最后一个日志文件尾部。
4.如权利要求1所述的文件***,其特征在于,包括一个适用于NVM命名空间管理的轻量级命名层,所述轻量级命名层由传统的虚拟文件***和底层文件***的命名空间整合后重新设计而成,所述轻量级命名层提供命名和权限检查功能,将虚拟文件***中的多个关键数据结构压缩成一个所述索引节点结构,采用一个全局的哈希表管理整个命名空间,所述文件***采用双向链表组织目录结构,在表示目录的索引节点中包含一个指向第一个子目录的指针,所有的子目录都由双向链表进行链接;所述文件树的每个叶子节点表示一个有连续空间的文件数据片段,用字节粒度的所述区段管理,记录了所述数据片段在文件中的起始偏移和连续的字节数,相应的,文件树的索引键值由这所述数据片段的起始偏移构成。
5.如权利要求1所述的文件***,其特征在于,当在内存上的哈希桶中***一个索引节点时,在NVM上申请新的索引节点并初始化为更新的信息,在日志中只记录所述索引节点的地址,不需记录更新的信息;当文件树***、删除或者更新区段时,数据日志需要将更新的区段地址记录到日志文件中,记录文件区段的更新时,先在NVM上申请新的区段并初始化为更新的信息,然后在数据日志中记录新区段的地址和旧的区段的地址。
6.如权利要求5所述的文件***,其特征在于,每一个日志文件都在文件起始位置包含了记录日志项位置的头、尾指针,所述头指针和尾指针分别指向一个更新操作涉及所有日志项的起始记录位置和终止记录位置;添加日志项时,首先读取头指针,从起始位置开始添加,当一个文件操作涉及的日志项全部添加完毕以后,再更新尾指针指向日志尾;全部日志项持久化以后,再维护哈希桶、目录链表、文件区段链表,修改NVM上涉及的邻接点的front和next域指针,以及位图,所述邻接点为front和next域所指向的节点,当NVM上所有信息全部持久化更新后,修改头指针以指向尾指针所指位置,即完成清理日志的工作。
7.如权利要求6所述的文件***,其特征在于,所述文件***发生***故障时,若头、尾指针指向相同的区域,则不进行***恢复;当头、尾指针指向不同区域时,根据日志中记录的索引节点和区段地址找到NVM相应的对象,根据其内容进行NVM上链表的维护及位图的更新等操作,然后根据NVM上恢复后的保持一致性状态的文件***信息,重建内存上的哈希表和文件树。
8.如权利要求1所述的文件***,其特征在于,在进行内存映射mmap操作时,所述文件***为避免回写未修改的内存映射的数据页,追踪操作***缺页中断过程,当发生数据页的缺页中断时,记录脏页信息;当同步共享内存区的文件数据到存储设备时,回写脏页,并将所述脏页的标志位清空,如果下次同步前没有再修改所述数据页,将不用再次回写该脏页。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201711133827.XA CN107862064B (zh) | 2017-11-16 | 2017-11-16 | 一个基于nvm的高性能、可扩展的轻量级文件*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201711133827.XA CN107862064B (zh) | 2017-11-16 | 2017-11-16 | 一个基于nvm的高性能、可扩展的轻量级文件*** |
Publications (2)
Publication Number | Publication Date |
---|---|
CN107862064A true CN107862064A (zh) | 2018-03-30 |
CN107862064B CN107862064B (zh) | 2021-09-10 |
Family
ID=61701797
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201711133827.XA Active CN107862064B (zh) | 2017-11-16 | 2017-11-16 | 一个基于nvm的高性能、可扩展的轻量级文件*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107862064B (zh) |
Cited By (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109543429A (zh) * | 2018-11-21 | 2019-03-29 | 武汉思普崚技术有限公司 | 一种适用于期望链接的双链表保护方法及装置 |
CN109582677A (zh) * | 2018-12-03 | 2019-04-05 | 东北大学 | 基于孩子节点的多粒度分布式读写锁的r树索引优化方法 |
CN109688006A (zh) * | 2018-12-24 | 2019-04-26 | 北京天元特通科技有限公司 | 支持目标集群动态探测的高性能网络日志消息分发方法 |
CN109918341A (zh) * | 2019-02-26 | 2019-06-21 | 厦门美图之家科技有限公司 | 日志处理方法及装置 |
CN109933570A (zh) * | 2019-03-15 | 2019-06-25 | 中山大学 | 一种元数据管理方法、***及介质 |
CN109976947A (zh) * | 2019-03-11 | 2019-07-05 | 北京大学 | 一种面向混合内存的掉电恢复的方法和*** |
CN110134657A (zh) * | 2019-04-08 | 2019-08-16 | 中国科学院计算技术研究所 | 基于非易失主存的文件***元数据操作加速方法和*** |
CN111158860A (zh) * | 2019-12-30 | 2020-05-15 | 咪咕文化科技有限公司 | 数据操作方法、电子设备及存储介质 |
CN111209342A (zh) * | 2020-01-13 | 2020-05-29 | 阿里巴巴集团控股有限公司 | 分布式***、数据同步与节点管理方法、设备及存储介质 |
CN111221776A (zh) * | 2019-12-30 | 2020-06-02 | 上海交通大学 | 面向非易失性内存的文件***的实现方法、***及介质 |
CN111444114A (zh) * | 2019-01-16 | 2020-07-24 | 阿里巴巴集团控股有限公司 | 一种非易失性内存中数据的处理方法、装置及*** |
CN111861484A (zh) * | 2019-04-24 | 2020-10-30 | 国际信任机器股份有限公司 | 适用于区块链与链下间协作的验证***与方法 |
CN112463542A (zh) * | 2020-12-15 | 2021-03-09 | 深圳供电局有限公司 | 日志异常原因诊断方法、装置、计算机设备和存储介质 |
CN112947856A (zh) * | 2021-02-05 | 2021-06-11 | 彩讯科技股份有限公司 | 一种内存数据的管理方法、装置、计算机设备及存储介质 |
CN112988680A (zh) * | 2021-03-30 | 2021-06-18 | 联想凌拓科技有限公司 | 数据加速方法、缓存单元、电子设备及存储介质 |
CN113051241A (zh) * | 2019-12-27 | 2021-06-29 | ***通信集团湖南有限公司 | 数据库持久化的方法、装置及设备 |
CN113127415A (zh) * | 2019-12-31 | 2021-07-16 | 浙江宇视科技有限公司 | 实时流文件的处理方法、装置、介质及电子设备 |
CN113377292A (zh) * | 2021-07-02 | 2021-09-10 | 北京青云科技股份有限公司 | 一种单机存储引擎 |
WO2021179575A1 (zh) * | 2020-03-08 | 2021-09-16 | 苏州浪潮智能科技有限公司 | 一种数据库一体机的存储方法、装置、设备和介质 |
CN113434092A (zh) * | 2021-07-07 | 2021-09-24 | 中国人民解放军国防科技大学 | 一种基于混合dram-nvm内存的指纹识别方法 |
CN113688099A (zh) * | 2021-08-09 | 2021-11-23 | 浪潮云信息技术股份公司 | 基于spdk的数据库存储引擎加速方法及*** |
WO2022089607A1 (zh) * | 2020-10-29 | 2022-05-05 | 第四范式(北京)技术有限公司 | 参数服务器节点的恢复方法和恢复*** |
CN114579529A (zh) * | 2022-05-07 | 2022-06-03 | 深圳市杉岩数据技术有限公司 | 一种基于重定向和日志混合的本地存储方法及*** |
CN114936215A (zh) * | 2022-06-07 | 2022-08-23 | 北京人大金仓信息技术股份有限公司 | 一种预写式日志的处理方法、存储介质与设备 |
CN115017128A (zh) * | 2022-05-26 | 2022-09-06 | 上海介方信息技术有限公司 | 基于corba中间件的轻量级日志服务设计方法及*** |
CN115048046A (zh) * | 2022-05-26 | 2022-09-13 | 北京华昱卓程软件有限公司 | 日志文件***以及数据管理方法 |
WO2022199400A1 (zh) * | 2021-03-23 | 2022-09-29 | 中兴通讯股份有限公司 | 持久内存文件***元数据的检索方法和装置、存储结构 |
CN117407374A (zh) * | 2023-12-12 | 2024-01-16 | 创云融达信息技术(天津)股份有限公司 | 一种基于分布式文件***的分布式锁实现方法和*** |
WO2024022330A1 (zh) * | 2022-07-25 | 2024-02-01 | 华为云计算技术有限公司 | 一种基于文件***的元数据管理方法及其相关设备 |
CN117931608A (zh) * | 2024-03-14 | 2024-04-26 | 麒麟软件有限公司 | 一种在vmcore中统计文件缓存占用的方法及装置、存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130290957A1 (en) * | 2012-04-26 | 2013-10-31 | International Business Machines Corporation | Efficient execution of jobs in a shared pool of resources |
CN103544045A (zh) * | 2013-10-16 | 2014-01-29 | 南京大学镇江高新技术研究院 | 一种基于hdfs的虚拟机镜像存储***及其构建方法 |
CN105868396A (zh) * | 2016-04-19 | 2016-08-17 | 上海交通大学 | 内存文件***的多版本控制方法 |
CN107016100A (zh) * | 2017-04-10 | 2017-08-04 | 重庆大学 | 一种基于非易失性内存文件***的元数据管理方法 |
-
2017
- 2017-11-16 CN CN201711133827.XA patent/CN107862064B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130290957A1 (en) * | 2012-04-26 | 2013-10-31 | International Business Machines Corporation | Efficient execution of jobs in a shared pool of resources |
CN103544045A (zh) * | 2013-10-16 | 2014-01-29 | 南京大学镇江高新技术研究院 | 一种基于hdfs的虚拟机镜像存储***及其构建方法 |
CN105868396A (zh) * | 2016-04-19 | 2016-08-17 | 上海交通大学 | 内存文件***的多版本控制方法 |
CN107016100A (zh) * | 2017-04-10 | 2017-08-04 | 重庆大学 | 一种基于非易失性内存文件***的元数据管理方法 |
Cited By (45)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109543429A (zh) * | 2018-11-21 | 2019-03-29 | 武汉思普崚技术有限公司 | 一种适用于期望链接的双链表保护方法及装置 |
CN109582677B (zh) * | 2018-12-03 | 2021-05-04 | 东北大学 | 基于孩子节点的多粒度分布式读写锁的r树索引优化方法 |
CN109582677A (zh) * | 2018-12-03 | 2019-04-05 | 东北大学 | 基于孩子节点的多粒度分布式读写锁的r树索引优化方法 |
CN109688006A (zh) * | 2018-12-24 | 2019-04-26 | 北京天元特通科技有限公司 | 支持目标集群动态探测的高性能网络日志消息分发方法 |
CN111444114B (zh) * | 2019-01-16 | 2023-06-13 | 阿里巴巴集团控股有限公司 | 一种非易失性内存中数据的处理方法、装置及*** |
CN111444114A (zh) * | 2019-01-16 | 2020-07-24 | 阿里巴巴集团控股有限公司 | 一种非易失性内存中数据的处理方法、装置及*** |
CN109918341A (zh) * | 2019-02-26 | 2019-06-21 | 厦门美图之家科技有限公司 | 日志处理方法及装置 |
CN109976947A (zh) * | 2019-03-11 | 2019-07-05 | 北京大学 | 一种面向混合内存的掉电恢复的方法和*** |
CN109933570A (zh) * | 2019-03-15 | 2019-06-25 | 中山大学 | 一种元数据管理方法、***及介质 |
CN110134657A (zh) * | 2019-04-08 | 2019-08-16 | 中国科学院计算技术研究所 | 基于非易失主存的文件***元数据操作加速方法和*** |
CN111861484B (zh) * | 2019-04-24 | 2024-04-02 | 国际信任机器股份有限公司 | 安全协定装置、验证方法、终端装置与终端装置执行的方法 |
CN111861484A (zh) * | 2019-04-24 | 2020-10-30 | 国际信任机器股份有限公司 | 适用于区块链与链下间协作的验证***与方法 |
CN113051241B (zh) * | 2019-12-27 | 2023-08-15 | ***通信集团湖南有限公司 | 数据库持久化的方法、装置及设备 |
CN113051241A (zh) * | 2019-12-27 | 2021-06-29 | ***通信集团湖南有限公司 | 数据库持久化的方法、装置及设备 |
CN111158860A (zh) * | 2019-12-30 | 2020-05-15 | 咪咕文化科技有限公司 | 数据操作方法、电子设备及存储介质 |
CN111221776A (zh) * | 2019-12-30 | 2020-06-02 | 上海交通大学 | 面向非易失性内存的文件***的实现方法、***及介质 |
CN111221776B (zh) * | 2019-12-30 | 2023-06-23 | 上海交通大学 | 面向非易失性内存的文件***的实现方法、***及介质 |
CN111158860B (zh) * | 2019-12-30 | 2024-02-23 | 咪咕文化科技有限公司 | 数据操作方法、电子设备及存储介质 |
CN113127415B (zh) * | 2019-12-31 | 2024-02-27 | 浙江宇视科技有限公司 | 实时流文件的处理方法、装置、介质及电子设备 |
CN113127415A (zh) * | 2019-12-31 | 2021-07-16 | 浙江宇视科技有限公司 | 实时流文件的处理方法、装置、介质及电子设备 |
CN111209342A (zh) * | 2020-01-13 | 2020-05-29 | 阿里巴巴集团控股有限公司 | 分布式***、数据同步与节点管理方法、设备及存储介质 |
CN111209342B (zh) * | 2020-01-13 | 2023-04-07 | 阿里巴巴集团控股有限公司 | 分布式***、数据同步与节点管理方法、设备及存储介质 |
WO2021179575A1 (zh) * | 2020-03-08 | 2021-09-16 | 苏州浪潮智能科技有限公司 | 一种数据库一体机的存储方法、装置、设备和介质 |
WO2022089607A1 (zh) * | 2020-10-29 | 2022-05-05 | 第四范式(北京)技术有限公司 | 参数服务器节点的恢复方法和恢复*** |
CN112463542B (zh) * | 2020-12-15 | 2023-06-02 | 深圳供电局有限公司 | 日志异常原因诊断方法、装置、计算机设备和存储介质 |
CN112463542A (zh) * | 2020-12-15 | 2021-03-09 | 深圳供电局有限公司 | 日志异常原因诊断方法、装置、计算机设备和存储介质 |
CN112947856B (zh) * | 2021-02-05 | 2024-05-03 | 彩讯科技股份有限公司 | 一种内存数据的管理方法、装置、计算机设备及存储介质 |
CN112947856A (zh) * | 2021-02-05 | 2021-06-11 | 彩讯科技股份有限公司 | 一种内存数据的管理方法、装置、计算机设备及存储介质 |
WO2022199400A1 (zh) * | 2021-03-23 | 2022-09-29 | 中兴通讯股份有限公司 | 持久内存文件***元数据的检索方法和装置、存储结构 |
CN112988680A (zh) * | 2021-03-30 | 2021-06-18 | 联想凌拓科技有限公司 | 数据加速方法、缓存单元、电子设备及存储介质 |
CN113377292B (zh) * | 2021-07-02 | 2024-02-02 | 北京青云科技股份有限公司 | 一种单机存储引擎 |
CN113377292A (zh) * | 2021-07-02 | 2021-09-10 | 北京青云科技股份有限公司 | 一种单机存储引擎 |
CN113434092B (zh) * | 2021-07-07 | 2022-04-01 | 中国人民解放军国防科技大学 | 一种基于混合dram-nvm内存的指纹识别方法 |
CN113434092A (zh) * | 2021-07-07 | 2021-09-24 | 中国人民解放军国防科技大学 | 一种基于混合dram-nvm内存的指纹识别方法 |
CN113688099A (zh) * | 2021-08-09 | 2021-11-23 | 浪潮云信息技术股份公司 | 基于spdk的数据库存储引擎加速方法及*** |
CN113688099B (zh) * | 2021-08-09 | 2023-10-13 | 上海沄熹科技有限公司 | 基于spdk的数据库存储引擎加速方法及*** |
CN114579529A (zh) * | 2022-05-07 | 2022-06-03 | 深圳市杉岩数据技术有限公司 | 一种基于重定向和日志混合的本地存储方法及*** |
CN115048046A (zh) * | 2022-05-26 | 2022-09-13 | 北京华昱卓程软件有限公司 | 日志文件***以及数据管理方法 |
CN115017128A (zh) * | 2022-05-26 | 2022-09-06 | 上海介方信息技术有限公司 | 基于corba中间件的轻量级日志服务设计方法及*** |
CN114936215A (zh) * | 2022-06-07 | 2022-08-23 | 北京人大金仓信息技术股份有限公司 | 一种预写式日志的处理方法、存储介质与设备 |
CN114936215B (zh) * | 2022-06-07 | 2024-06-11 | 北京人大金仓信息技术股份有限公司 | 一种预写式日志的处理方法、存储介质与设备 |
WO2024022330A1 (zh) * | 2022-07-25 | 2024-02-01 | 华为云计算技术有限公司 | 一种基于文件***的元数据管理方法及其相关设备 |
CN117407374A (zh) * | 2023-12-12 | 2024-01-16 | 创云融达信息技术(天津)股份有限公司 | 一种基于分布式文件***的分布式锁实现方法和*** |
CN117407374B (zh) * | 2023-12-12 | 2024-02-27 | 创云融达信息技术(天津)股份有限公司 | 一种基于分布式文件***的分布式锁实现方法和*** |
CN117931608A (zh) * | 2024-03-14 | 2024-04-26 | 麒麟软件有限公司 | 一种在vmcore中统计文件缓存占用的方法及装置、存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN107862064B (zh) | 2021-09-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107862064A (zh) | 一个基于nvm的高性能、可扩展的轻量级文件*** | |
Kwon et al. | Strata: A cross media file system | |
US9965483B2 (en) | File system | |
CN105453021B (zh) | 用于原子存储操作的***和方法 | |
US8984239B2 (en) | Hardware and operating system support for persistent memory on a memory bus | |
CN103765393B (zh) | 存储*** | |
JP5695040B2 (ja) | ファイルシステム | |
Dong et al. | Soft updates made simple and fast on non-volatile memory | |
Hwang et al. | Heapo: Heap-based persistent object store | |
CN110062925A (zh) | 用于云集成的快照元数据布置 | |
US9324367B1 (en) | SMR-aware append-only file system | |
US20230046216A1 (en) | Data management system and method of controlling | |
Cao et al. | State of the art: Where we are with the ext3 filesystem | |
US11741073B2 (en) | Granularly timestamped concurrency control for key-value store | |
CN110134657A (zh) | 基于非易失主存的文件***元数据操作加速方法和*** | |
CN106020736B (zh) | 一种内存文件***中的数据一致性更新方法 | |
US10628391B1 (en) | Method and system for reducing metadata overhead in a two-tier storage architecture | |
Yang et al. | A Highly Non-Volatile Memory Scalable and Efficient File System | |
CN105912277A (zh) | 在虚拟机镜像中实现文件***单写日志的方法 | |
Sha et al. | The design and implementation of an efficient user-space in-memory file system | |
Liu et al. | CFFS: A Persistent Memory File System for Contiguous File Allocation With Fine-Grained Metadata | |
Sears et al. | Segment-based recovery: write-ahead logging revisited | |
Nguyen et al. | Why Files If You Have a DBMS | |
US12014070B2 (en) | Method, device, and computer program product for storage management | |
CN117076413B (zh) | 一种支持多协议互通的对象多版本存储*** |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |