ROFS文件系统介绍

ROFS（Ring Objects File System）文件系统介绍ROFS文件系统是一套专门针对海量视频录像系统设计的高效健壮的专用文件系统。

传统上的视频录像技术大都采用在普通文件系统上用视频录像文件的方式来进行录像应用，因为普通文件系统固有的特点，导致在做视频存储应用时导致很多问题：

●普通文件系统以簇为单位分配磁盘空间，为了空间利用率，簇的字节数

一般都很小，文件反复读写/创建/删除导致簇不断被分配和释放，时间

稍微一长就会产生磁盘碎片，导致磁盘读写性能急剧下降，严重时甚至

会损坏磁盘。

●普通文件系统采用元数据来保证数据的一致性，鲁棒性不强，一旦元数

据损害，即使数据部分没有损害，也无法还原。而超过100路的并发录

像，若使用普通文件系统，元数据损坏的机率极大。

●由于文件系统的限制，文件不能太大，也不能太小，一般采用几分钟一

个文件进行录像，难以实现检索几秒以前的录像数据，很难支持对正在

录像的文件的检索回放。

●扫描磁盘文件、清理旧录像、检索等操作效率低下，且格式化非常缓慢。

针对使用普通文件系统的传统上视频录像技术的诸多问题，东方网力公司专门针对海量视频录像应用，开发了ROFS文件系统，有效的解决了上述普通文件系统无法/很难解决的问题。

ROFS文件系统采用完全具有自主知识产权的专有文件格式（已获国家专利）设计，可有效避免磁盘碎片的产生，写数据和清理旧数据时几乎没有磁盘块的分配/释放动作，最大限度的提高了硬盘的读写数据性能，写录像数据的速度比传统录像方式要快很多，磁盘寿命也得到了最大限度的保护（最大限度的减少了磁头移动频率）。使用ROFS录像系统，磁盘可以长时间大压力读写而不会有任何磁盘碎片产生，性能也几乎不会有任何下降。

ROFS文件系统不但拥有最高的磁盘读写性能，而且还有有极高的鲁棒性。系统采用大数据块方式读写磁盘，但以视频帧为单位进行提交，视频帧是一个最小可修复的单位，任何一个视频帧损坏不会影响其它视频帧，所以即使在没有任何RAID防护的情况下的硬盘物理损坏也只会损失非常短的一小段录像，如果是软损坏（程序错误导致的损坏）则甚至只会仅仅损失一帧或数帧(<1秒)而已，

又因为ROFS为完全自主的文件系统，任何部分数据损坏都不会影响到其它地方的数据（没有破坏的完好数据全部可以修复）。所以ROFS有极高的鲁棒性。

因为以视频帧为基本存储单位，一旦一个视频帧写入完成就立即可以进行检索，采用ROFS的录像系统可以检索到40毫秒前的录像。另外，视频帧的索引内建在ROFS中，所以可以快速地定位到任何一个视频帧立即开始播放，其格式化也非常迅速。

下面就ROFS文件系统的一些技术特征做一个简要介绍：

ROFS（Ring Objects File System）文件系统是一个基于流式文件支持的以环形队列为基本结构的分层流媒体存储系统，系统分为五层

核心逻辑层为ROFS的核心逻辑部分，建立在单一的流式设备上，把空间依次分为以下四部分，如图：

信息存储区

数据包存储区

引信息区

信息区

固定块信息

一存储……

据包1据包2据包3据包4据包5

二存储信息信息

区域区域

从左到有依次为

1、超级块区，包括固定块信息和存储区域信息

2、时间段信息区

3、数据包（Package ）索引区

4、数据区 概念定义：

1、ROFS 存储的最小单元为片（Slice ），分为普通片（Slice ），关键片

（KeySlice ）。一般在使用中Slice 对应视频帧，KeySlice 对应视频I 帧。

2、提交、定位、删除的最小单位为数据包（Package ），Package 由一个

KeySlice 和0到多个Slice 组成。数据区由首尾相接的Package 填充，相邻Package 之间无空隙。

3、索引（Index ），记录了Package 在流式设备里面的绝对偏移地址（用

64位整数表示）。

4、时间段（Segment ），记录了1到多个Package 集合的时间信息。

主要数据结构介绍： 1、固定信息块主要字段：

+------------+

| |

| rofsID | char[16]，ROFS文件系统标识字符串

/ ... /

+------------+

| |

| version | 低UINT32（次版本号） + 高UINT32（主版本号）| |

+------------+

| |

| alignSize | INT64，设备的读写对齐size

| |

+--------------+

| |

|deviceTotalLen| INT64，设备总长度（bytes）

| |

+----------------+

| |

|immutablyAreaLen| INT64，固定信息块占用长度（bytes）

| |

+------------------+

| |

|timeSegmentAreaLen| INT64，时间段区占用长度（bytes）

| |

+-------------------+

| |

|packageIndexAreaLen| INT64，Package索引区占用长度（bytes）| |

+---------------------+

| maxTimeSegMSELs | UINT32，时间段最大允许值（毫秒）

+---------------------+

| averagePackageBytes | UINT32，建议Package平均大小值

+---------------------+

| slicesPerPackage | UINT32，每个Package平均的Slice数

+---------------------+

| |

| sumCRC | INT64，固定信息块校验和（前面所有INT64之和）

| |

+------------+

/ ... / x个对齐字节(>=0)，内容未定义

+------------+

2、存储数据信息主要字段：

+------------+

| |

| updateNum1 | INT64，更新流水号1，每次写动作唯一

| |

+-----------------+

| |

|timeSegBeginIndex| INT64，时间段区第一个项的环形队列下标号

| |

+-----------------+

| |

| timeSegCount | INT64，时间段区索引项数

| |

+----------------------+

| |

|packageIndexBeginIndex| INT64，Package索引区第一项环形队列下标号| |

+----------------------+

| |

|packageBeginSeriNum| INT64，第一个Package的序列号

| |

+-------------------+

| |

| packageCount | INT64，总Package数量

| |

+---------------+

| |

|packageBeginPos| INT64，Package数据的开始位置

| |

+--------------------------+

|maxPackageStatisticalBytes| UINT32，最大的Package大小（统计值）+--------------------------+

| fstDeletedCount| UINT32，第一个时间段被删掉的Package数

+----------------+

| |

|fstDeletedBytes| INT64，第一个时间段被删掉的Package的字节数

| |

+---------------+

|fstDeletedMSELs| UINT32，第一个时间段被删掉的Package的时间长度+---------------+

| reserve | UINT32，填0保留

+---------------+

| |

| updateNum2 | INT64，更新流水号2，与更新流水号1一致

| |

+------------+

| |

| sumCRC | INT64，存储数据信息校验和（前面所有INT64之和）

| |

+------------+

/ ... / x个对齐字节(>=0)，内容未定义

+------------+

3、数据片信息(SliceInfo)结构字段：

+------------+

| sliceFlag | UINT32， Slice的类型标志

+------------+

| timeLen | UINT32，Slice的时间长度

+------------+

| |

| beginTime | INT64，Slice的开始时间

| |

+------------+

4、Package结构字段：

+------------+

| magicUINT32 | UINT32，32位Package魔数（用于数据的灾难恢复）

+------------+

/ ... / 第一个Slice（一定是KeySlice）的数据

+------------+

/ ... / 其它Slice数据

+------------+

/ sliceInfo / SliceInfo，第一个Slice的相关信息

+------------+

/ ... / SliceInfo，其它Slice的相关信息

+------------+

| |

| seriNum | INT64，Package的序列号（用于数据的灾难恢复）

| |

+------------+

| |

| beginTime | INT64，Package的开始时间

| |

+------------+

| timeLen | UINT32，Package的时间长度，毫秒(ms)

+------------+

| sliceCount | UINT16，Package的slice数量

+------------+

| chanID | UINT16，Package的通道类型ID（用于数据的灾难恢复）+------------+

/ sumCRC / UINT32，Package的求和校验数（用于数据的灾难恢复）+------------+ 对于Read()读取出来的数据，不保证校验正确

5、数据包索引项字段：

+------------+

| |

| offset | INT64，偏移地址（相对于数据区起始位置）

| |

+------------+

| |

| beginTime | INT64，Package开始时间

| |

+------------+

| timeLen | UINT32，Package时间长度（毫秒）

+------------+

| bytesLen | UINT32，Package字节长度

+------------+

| sliceCount | UINT16，Package的slice数量

+------------+

| chanID | UINT16，Package的通道类型ID（用于数据的灾难恢复）+------------+

| reserve | UINT32，填0保留

+------------+

6、时间段信息（Segment）字段：

+------------+

| |

| index | INT64，第一个Package在Package索引区里的下标号

| |

+------------+

| |

| totalBytes | INT64，本时间段所有Package的总长度

| |

+------------+

| |

| beginTime | INT64，本段开始时间

| |

+------------+

| count | UINT32，本时间段的Package数量

+------------+

| timeLen | UINT32，本时间段时间长度（最长表示约42天）+------------+

写入数据片（Slice）简要流程图：

配置界面

格式化界面

打开设备

录像监视主界面

录像明细监视界面

修复界面/进度监视

ROFS2.0特性设计（单机特性）

1、磁盘故障（坏扇区等）报警、标记、容错。

2、超级块信息多重冗余保护。

3、设备热插拔。

4、可变长分区（分配单元为大磁盘块）。

5、配额管理。

6、动态虚拟分区管理。

基于ROFS2.0的云存储特性

1、海量存储。

2、存储分级，至少有三级：终端存储、区域存储、中心存储。

3、冗余存储，每个存储级有一定数据冗余。

4、网络存储设备热拔插，设备的动态接入/断开，所有存储服务功能不受影

响。

5、对外服务透明性。

6、整个存储系统高效、健壮、低成本。

几种Nand flash文件系统的对比

几种Nand flas文件系统的对比 1.来源：NLE-FFS: A Flash File System with PRAM for Non-linear Editing For thesedevices, NAND flash memory has became the most attractive storage medium due to outstanding characteristics such as its increased capacity, low power consumption, small size and light weight. For the efficient management of NAND flashmemory, several flash file systems have been proposed, including JFFS2, YAFFS2, CFFS and PFFS. several file systems such as MNFS,NAMU and ScaleFFS have been designed for real-time recording /playback and large-capacity storage. A. YAFFS2 YAFFS2 is the most widely employed file system for NAND flash memory. YAFFS2 essentially saves the object ID (file ID) and the chunk (page) number in the spare region to show the offset of a page and the owner file of the page. Therefore, YAFFS2 reads the spare regions and object headers to establish the metadata in memory. Although YAFFS2 is designed to support NAND flash memory, it has scalability problems. With YAFFS2, the location of the updated page is saved in NAND flash pages or spare regions, as shown in Fig. 10 (a); hence, the file system

文件系统介绍

文件系统简介： 理论上说一个嵌入式设备如果内核能够运行起来，且不需要运行用户进程的话，是不需要文件系统的。文件系统简单的说就是一种目录结构，由于linux操作系统的设备在系统中 是以文件的形式存在，将这些文件进行分类管理以及提供和内核交互的接口，就形成一定的目录结构也就是文件系统。文件系统是为用户反映系统的一种形式，为用户提供一个检测控制系统的接口。 根文件系统，就是一种特殊的文件系统。那么根文件系统和普通的文件系统有什么区别呢？由于根文件系统是内核启动时挂在的第一个文件系统，那么根文件系统就要包括Linux 启动时所必须的目录和关键性的文件，例如Linux启动时都需要有用户进程init对应的文件，在Linux挂载分区时Linux一定会找/etc/fstab这个挂载文件等，根文件系统中还包括了许多的应用程序，如/bin目录下的命令等。任何包括这些Linux 系统启动所必须的文件的文件系统都可以称为根文件系统。 Linux支持多种文件系统，包括ext2、ext3、vfat、ntfs、iso9660、jffs、ramfs和nfs 等，为了对各类文件系统进行统一管理，Linux引入了虚拟文件系统VFS，为各类文件系统提供一个统一的操作界面和应用编程接口。下图是linux文件系统层次关系图。 MTD MTD(memory technology device内存技术设备)是用于访问memory设备（ROM、flash）的Linux的子系统。MTD的主要目的是为了使新的memory设备的驱动更加简单，为此它在硬件和上层之间提供了一个抽象的接口。MTD的所有源代码在/drivers/mtd子目录下。

JFFS文件系统和YAFFS文件系统的比较

JFFS文件系统和YAFFS文件系统的比较 NAND flash文件系统JFFS2和YAFFS比较JFFS是由瑞典的Axis Communications Ab公司开发的(1999,以GNU发布),针对flash设备的特性为嵌入式设备开发的.(我边上的兄弟曾想去那里作毕业设计) JFFS1和JFFS2的设计中都考虑到了FLASH的特性特别是满足了上述3个条件,包括了垃圾回收,坏块管理等功能. 这两种文件系统属于LFS(Log-structured File System).这种文件系统的特点是一旦数据出错,容易恢复,但是系统运行是需要占用一定的内存空间,这些空间就是用来存储”log”的. JFFS的缺点就是加载时间太长,因为每次加载都需要将FLASH上的所有节点(JFFS的存储单位)到内存,这样也占用了可观的内存空间.除此之外,”circle log”设计使得在对文件数据进行所有的数据都会被重写,这样造成不必要的时间,同时也会减少FLASH的寿命. JFFS2对JFFS1作了些改进,比如所需的内存变少了,垃圾回收机制也优化了. 针对JFFS1,JFFS2的缺点,JFFS3出现了. YAFFS1 ">“Yet Another Flash File System”作者是新西兰的Charles Manning为一家名叫Alpha one 的公司(https://www.sodocs.net/doc/7717453121.html,/)设计的,是第一个为NAND Flash设计的文件系统.共两个版本YAFFS1 和YAFFS2. YAFFS1支持512Bytes/Page的NAND Flash;后者YAFFS2支持2kBytes/Page的NAND Flash. YAFFS文件系统也属于LFS. 跟其他文件系统比较,它具有更好的可移植性,甚至可以使用在没有操作系统的设备上(called “YAFFS/Direct”). YAFFS采用模块化设计,虽然最初是用在linux系统上的,但是也已经移植到其他系统比如wince. 还有个突出的优点是它在mount的时候需要很少的内存.(如果是小页—512byte/page,每1MByte NAND大约需要4KBytes内存;大页需要大概1KBytes RAM/1MByte NAND) JFFS与YAFFS比较,两者各有长处. 一般来说,对于小于64MBytes的NAND Flash,可以选用JFFS;如果超过64MBytes,用YAFFS比较合适.

分布式文件系统设计方案

分布式文件系统（DFS）解决方案 一“分布式文件系统（DFS）”概述 DFS并不是一种文件系统，它是Windows Server System上的一种客户/服务器模式的网络服务。它可以让把局域网中不同计算机上的不同的文件共享按照其功能组织成一个逻辑的分级目录结构。系统管理员可以利用分布式文件系统(DFS)，使用户访问和管理那些物理上跨网络分布的文件更加容易。通过DFS，可以使分布在多个服务器或者不同网络位置的文件在用户面前显示时，就如同位于网络上的一个位置。用户在访问文件时不再需要知道和指定它们的实际物理位置。 例如，如果您的销售资料分散在某个域中的多个存储设备上，您可以利用DFS 使其显示时就好像所有的资料都位于同一网络共享下，这样用户就不必到网络上的多个位置去查找他们需要的信息。 二部署使用“分布式文件系统（DFS）”的原因 ●访问共享文件夹的用户分布在一个站点的多个位置或多个站点上； ●大多数用户都需要访问多个共享文件夹； ●通过重新分布共享文件夹可以改善服务器的负载平衡状况； ●用户需要对共享文件夹的不间断访问；

●您的组织中有供内部或外部使用的Web 站点； ●用户访问共享文件需要权限。 三“分布式文件系统（DFS）”类型 可以按下面两种方式中的任何一种来实施分布式文件系统： 1．作为独立的分布式文件系统。 ●不使用Active Directory。 ●至多只能有一个根目录级别的目标。 ●使用文件复制服务不能支持自动文件复制。 ●通过服务器群集支持容错。 2．作为基于域的分布式文件系统。 ●必须宿主在域成员服务器上。 ●使它的DFS 名称空间自动发布到Active Directory 中。 ●可以有多个根目录级别的目标。 ●通过FRS 支持自动文件复制。 ●通过FRS 支持容错。 四分布式文件系统特性 除了Windows Server System 中基于服务器的DFS 组件外，还有基于客户的DFS 组件。DFS 客户程序可以将对DFS 根目录或DFS 链接的引用缓存一段时间，该时间由管理员指定。此存储和读取过程对于

第一次挂载jffs2文件系统,出现：Node header CRC failed at

第一次挂载jffs2文件系统，出现：Node header CRC failed at 使用的bootloader：redboot kernel版本：2.6.29 flash类型：NOR FLASH. 制作jffs2的命令： mkfs.jffs2 -U -d /mnt/winF/tet/romfs -D devtable.jffs2.txt -l -e 0x10000 -p -n -o /tftpboot/jffs2fs.img "-e":表示flash的擦除块大小为0x10000,这个值很重要，可以从datasheet中得到。 "-p": Pad output to SIZE bytes with 0xFF. If SIZE is not specified, the output is padded to the end of the final erase block. 烧写命令： load -r -v -h 172.21.73.101 -b 0x8000 kernel.lzo fis create -b 0x8000 -l 0x200000 -s 0x200000 -f 0x7F060000 -e 0x8000 kernel.lzo load -r -v -h 172.21.73.101 -b 0x100000 jffs2fs.img fis write -b 0x100000 -f 0x7F260000 -l 0x250000 fis create -f 0x7F260000 -l 0x590000 jffs2.img reset 问题描述： 第一次启动，会出现CRC错误信息，如下： Shell invoked to run file: /etc/rc Welcome to ____ _ _ / __| ||_| _ _| | | | _ ____ _ _ _ _ | | | | | | || | _ \| | | |\ \/ / | |_| | |__| || | | | | |_| |/ \ | ___\____|_||_|_| |_|\____|\_/\_/ | | |_| ADVANTECH eAutomation For further information check: https://www.sodocs.net/doc/7717453121.html,/ https://www.sodocs.net/doc/7717453121.html,/eAutomation/ Execution Finished, Exiting Sash command shell (version 1.1.1) /> JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x06ddc8.

3种分布式文件系统

第一部分CEPH 1.1 特点 Ceph最大的特点是分布式的元数据服务器通过CRUSH，一种拟算法来分配文件的locaiton，其核心是 RADOS（resilient automatic distributed object storage)，一个对象集群存储，本身提供对象的高可用，错误检测和修复功能。 1.2 组成 CEPH文件系统有三个主要模块： a)Client：每个Client实例向主机或进程提供一组类似于POSIX的接口。 b)OSD簇：用于存储所有的数据和元数据。 c)元数据服务簇：协调安全性、一致性与耦合性时，管理命名空间（文件名和 目录名） 1.3 架构原理 Client：用户 I/O：输入/输出 MDS：Metadata Cluster Server 元数据簇服务器 OSD：Object Storage Device 对象存储设备

Client通过与OSD的直接通讯实现I/O操作。这一过程有两种操作方式： 1. 直接通过Client实例连接到Client； 2. 通过一个文件系统连接到Client。 当一个进行打开一个文件时，Client向MDS簇发送一个请求。MDS通过文件系统层级结构把文件名翻译成文件节点（inode），并获得节点号、模式（mode）、大小与其他文件元数据。注意文件节点号与文件意义对应。如果文件存在并可以获得操作权，则MDS通过结构体返回节点号、文件长度与其他文件信息。MDS同时赋予Client操作权（如果该Client还没有的话）。目前操作权有四种，分别通过一个bit表示：读（read）、缓冲读（cache read）、写（write）、缓冲写（buffer write）。在未来，操作权会增加安全关键字，用于client向OSD证明它们可以对数据进行读写（目前的策略是全部client 都允许）。之后，包含在文件I/O中的MDS被用于限制管理能力，以保证文件的一致性与语义的合理性。 CEPH产生一组条目来进行文件数据到一系列对象的映射。为了避免任何为文件分配元数据的需要。对象名简单的把文件节点需要与条目号对应起来。对象复制品通过CRUSH（著名的映射函数）分配给OSD。例如，如果一个或多个Client打开同一个文件进行读操作，一个MDS会赋予他们读与缓存文件内容的能力。通过文件节点号、层级与文件大小，Client可以命名或分配所有包含该文件数据的对象，并直接从OSD簇中读取。任何不存在的对象或字节序列被定义为文件洞或0。同样的，如果Client打开文件进行写操作。它获得使用缓冲写的能力。任何位置上的数据都被写到合适的OSD上的合适的对象中。Client 关闭文件时，会自动放弃这种能力，并向MDS提供新的文件大小（写入时的最大偏移）。它重新定义了那些存在的并包含文件数据的对象的集合。 CEPH的设计思想有一些创新点主要有以下两个方面： 第一，数据的定位是通过CRUSH算法来实现的。

嵌入式linux下的文件系统

嵌入式linux下常见的文件系统RomFS：只读文件系统，可以放在ROM空间，也 可以在系统的RAM中，嵌入式linux中常用来作 根文件系统 ?RamFS：利用VFS自身结构而形成的内存文件系 统，使用系统的RAM空间 ?JFFS/JFFS2：为Flash设计的日志文件系统?Yaffs：专门为Nand Flash设计 ?proc：为内核和内核模块将信息发送给进程提 供一种机制，可以查看系统模块装载的信息?devFS：设备文件系统 Linux上的Ext2fs ?支持4 TB 存储、文件名称最长1012 字符 ?可选择逻辑块 ?快速符号链接 ?Ext2不适合flash设备 ?是为象IDE 设备那样的块设备设计的，逻辑块大小必 须是512 byte、1 KB、2KB等 ?没有提供对基于扇区的擦除／写操作的良好管理 ?如果在一个扇区中擦除单个字节，必须将整个扇区复制到RAM，然后擦除，再重写入

?在出现电源故障时，Ext2fs 是不能防止崩溃的 ?文件系统不支持损耗平衡，缩短了flash的寿命 jffs/jffs2文件系统的优缺点 ?日志文件系统 ?提供了更好的崩溃、掉电安全保护 ?jffs2支持对flash的均匀磨损 ?在扇区级别上执行闪存擦除／写／读操作要 比Ext2文件系统好 ?文件系统接近满时，JFFS2 会大大放慢运行 速度——垃圾收集 Nand上yaffs文件系统的优势 ?专门为Nand flash设计的日志文件系统 ?jffs／jffs2不适合大容量的Nand flash ?jffs的日志通过jffs_node建立在RAM中，占用RAM空间：对于128MB的Nand大概需要4MB的空间来维护节点 ?启动的时候需要扫描日志节点，不适合大容量 的Nand flash ?FAT系统没有日志 编译yaffs文件系统 ?mtd的最新补丁升级？ ?接口更新，适合与yaffs

不同文件系统的比较

几种文件系统比较 嵌入式系统中比较常用的文件系统为JFFS、JFFS2、CRAMFS和YAFFS。 J f f s2:日志闪存文件系统版本2(J o u r n a l l i n g F l a s h F i l e S y s t e m v2) JFFS2主要应用于NOR Flash，可读写，支持数据压缩，安全保护等 特点。存储空间已满或接近满时，JFFS2文件系统的运行速度却由于垃 圾收集的原因而放慢。不适合用于NAND Flash，NAND Flash的容量一 般比较大，JFFS2文件系统为维护日志节点所占用的内存空间也迅速增大，因此JFFS2在挂载时需要很长时间来扫描整个FLASH的内容，用以找出所有的日志节点并建立文件结构，这样就会极大的降低系统的运行 效率。 y a f f s：Y e t A n o t h e r F l a s h F i l e S y s t e m yaffs/yaffs2是专为嵌入式系统使用NAND型闪存而设计的日 志型文件系统。不支持数据压缩，速度快，挂载时间很短，对内存 的占用较小。支持跨平台。yaffs/yaffs2自带NAND芯片的驱动， 并且为嵌入式系统提供了直接访问文件系统的API。yaffs仅支持 小页(512 Bytes) NAND闪存，yaffs2可支持大页(2KB) NAND闪存。 同时，yaffs2在内存空间占用、垃圾回收速度、读/写速度等方面 均有大幅提升。 C r a m f s C o m p r e s s e d R O M F i l e S y s t e m 是一种只读的压缩文件系统。它也基于MTD驱动程序。降低 了系统成本。以压缩方式存储，在运行时解压缩，不支持应用程序 以XIP方式运行，需要将程序拷到RAM里去运行，它的效率高，速 度快，其只读的特点保护文件系统免受破坏，提高了系统的可靠性。 R o m f s 文件系统是一种简单的只读文件系统，不支持动态擦写，按顺 序存放数据，因而支持应用程序以XIP片内运行方式运行，在系统 运行时，节省RAM空间。uClinux系统通常采用Romfs文件系统。 Ramdisk不是一个实际的文件系统，而是一种将实际的文件系 统装入内存的机制，并且可以作为根文件系统。Ramdisk将一些 经常被访问而又不会更改的文件放在内存中，用以提高系统的性能。 R a m f s 是基于内存的文件系统，工作于虚拟文件系统(VFS)层，不能格式化，在创建时可以指定其最大能使用的内存大小，文件系统大小可随所

典型分布式文件系统概述

分布式文件系统概述（一） 杨栋 yangdonglee@https://www.sodocs.net/doc/7717453121.html, 2006-12 摘要 文件系统是操作系统用来组织磁盘文件的方法和数据结构。传统的文件系统指各种UNIX平台的文件系统，包括UFS、FFS、EXT2、XFS等，这些文件系统都是单机文件系统，也称本地文件系统。随着网络的兴起，为了解决资源共享问题，出现了分布式文件系统。分布式文件系统是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。本文1简要回顾了本地文件系统，然后按照发展例程大致介绍了2006年之前各时期主要的分布式文件系统，最后从设计目标、体系结构及关键技术等方面比较了各个分布式文件系统的异同。目前很火的Hadoop文件系统、S3文件系统都是从NFS等早期文件系统一步步演化而来的，了解分布式文件系统的历史，有助于大家更加深刻地领会分布式文件系统的精髓。 1本文写于2006年底，借鉴了别人的大量资料，目的是为了与同学们分享分布式文件系统的发展史。笔者在硕士期间跟随中科院计算所的孟老师、熊老师和唐荣锋进行分布式文件系统的研究和开发。分布式文件系统源远流长，本文只是选择了其发展史上的部分实例进行简单描述，由于笔者水平十分有限，错误之处难免很多，各位同学发现问题之后麻烦回复邮件到yangdonglee@https://www.sodocs.net/doc/7717453121.html,，我会尽全力完善，或者请各位同学自行修正。笔者目前在百度进行云计算方面的研究和开发，希望有兴趣的同学一起进行探讨。

目录 1．引言 (5) 2．本地文件系统 (5) 2.1FFS (6) 2.2LFS (6) 2.3Ext3 (7) 3．分布式文件系统 (7) 3.1 发展历程 (7) 3.2分布式文件系统分类 (8) 3.2.1 实现方法 (8) 3.2.2研究状况 (8) 3.3 NFS (9) 3.3.1概述 (9) 3.3.2 体系结构 (9) 3.3.3 通信机制 (10) 3.3.4进程 (10) 3.3.5 命名 (10) 3.3.6 同步机制 (11) 3.3.7 缓存和复制 (11) 3.3.8 容错性 (12) 3.3.9 安全性 (13) 3.4 AFS、DFS、Coda和InterMezzo (13) 3.5 SpriteFS和Zebra (14) 3.6xFS (16) 3.6.1 概述 (16) 3.6.2 体系结构 (16) 3.6.3 通信 (16) 3.6.4 进程 (17) 3.6.5 命名 (18) 3.6.6 缓存 (19)

uClinux下Nor Flash的JFFS2文件系统构建

uClinux 下 Nor Flash 的 JFFS2 文件系统构建 摘要目前的嵌入式系统多使用作为主存，因此，如何有效管理上的数 据非常重要。 文章以 39160 芯片为例， 讨论了在上建立ｕ的 2 文件系统的一般步骤， 从而为上的数据管理提供了理想的选择方式。 关键词ｕ；；；2；文件系统嵌入式系统正随着Ｉｎｔｅｒｎｅｔ的 发展而在各个领域得到广泛的应用，作为嵌入式应用的核心，嵌入式Ｌｉ ｎｕｘ以其自由软件特性正日益被人们看好。 Ｌｉｎｕｘ具有内核小、效率高、源代码开放等优点，还内涵了完整 的ＴＣＰ／ＩＰ网络协议，因此非常适于嵌入式系统的应用。 而作为专门运行于没有ＭＭＵ的微处理器的嵌入式操作系统，ｕＣｌ ｉｎｕｘ更是得到广泛应用。 当前的嵌入式系统开发，需要方便灵活的使用Ｆｌａｓｈ。 ＮＯＲ和ＮＡＮＤ是现在市场上两种主要的非易失闪存技术。 Ｉｎｔｅｌ于１９８８年首先开发出ＮＯＲｆｌａｓｈ技术，彻底改 变了原先由ＥＰＲＯＭ和ＥＥＰＲＯＭ一统天下的局面。 ＮＯＲ的特点是芯片内执行 ＸＩＰ ｅＸｅ-ｃｕｔｅＩｎＰｌａ
ｃｅ ，这样应用程序可以直接在ｆｌａｓｈ闪存内运行，不必再把代码 读到系统ＲＡＭ中。

ＮＯＲ的传输效率很高，在１～４ＭＢ的小容量时具有很高的成本效 益，因此在嵌入式系统得到广泛的应用。 １ＪＦＦＳ２文件系统简介ｕＣｌｉｎｕｘ通常默认ＲＯＭＦＳ作 为根文件系统，它相对于一般的ＥＸＴ２文件系统具有节约空间的优点。 但是ＲＯＭＦＳ是一种只读的文件系统，不支持动态擦写保存。 虽然对于需要动态保存的数据可以采用虚拟ｒａｍ盘的方法来保存， 但当系统掉电后，ｒａｍ盘的内容将全部丢失，而不能永久保存，因此需 要实现一个可读写的文件系统。 ＪＦＦＳ２文件系统便是一个很好的选择。 ＪＦＦＳ文件系统是瑞典Ａｘｉｓ通信公司开发的一种基于Ｆｌａ ｓｈ的日志文件系统，它在设计时充分考虑了Ｆｌａｓｈ的读写特性和用 电池供电的嵌入式系统的特点，在这类系统中必需确保在读取文件时，如 果系统突然掉电，其文件的可靠性不受到影响。 对ＲｅｄＨａｔ的ＤａｖｉｄＷｏｏｄｈｏｕｓｅ进行改进后，形成 了ＪＦＦＳ２。 主要改善了存取策略以提高ＦＬＡＳＨ的抗疲劳性，同时也优化了碎 片整理性能，增加了数据压缩功能。 需要注意的是，当文件系统已满或接近满时，ＪＦＦＳ２会大大放慢 运行速度。 这是因为垃圾收集的问题。 范文先生网收集整理ＪＦＦＳ２的底层驱动主要完成文件系统对Ｆ ｌａｓｈ芯片的访问控制，如读、写、擦除操作。

JFFS2文件系统的制作

使用新的busybox-1.13.3制作jffs2文件系统 由于之前使用的文件系统中的busybox是1.5版本，结果很多工具都没有完善，这一次，在https://www.sodocs.net/doc/7717453121.html,上下载了当前的最新稳定版本，busybox-1.13.3来制作，总算搞定了，但也出现了一些问题，贴出我的过程跟大家分享一下，也给有需要的人一点帮助，希望如此。 全文如下： 2009-3-26 陈纪煌 今天尝试了移植新的文件系统，使用的是busybox-1.13.3稳定版本 由于之前所使用的版本是busybox-1.5.0，结果发现很多东西无法支持，比如nfs无法挂在，并且clear等工具无法正常使用 所以下了一个新的版本进行尝试 1.解压该包 tar xf busybox-1.13.3.tar.bz2 cd busybox-1.13.3 2.修改Makefile 找到 CROSS_COMPILE ?= 修改为CROSS_COMPILE ?=arm-linux- 找到 ARCH ?= $(SUBARCH) 修改为 ARCH ?= arm 3.进行默认配置 make defconfig 4.对配置信息进行修改 make menuconfig 检查Miscellaneous Utilities---> taskset 是否已经去除 同时设置如下： Busybox Settings ---> Build Options --->

[*]Build BusyBox as a static binry (no shared libs) ()Cross Compiler prefix=/usr/local/arm/3.4.1/bin/ Installation Options ---> [*]Don't use /usr BusyBox installation=${PROJECT}/rootfs/rootfs_1.13 这几个设置对于之前做过相关工作的人来说是比较熟悉的，都很容易知道为何如此做。make make install 编译出错 修改networking/interface.c 818行改为.type = -1 这样编译就能通过。我使用gcc来编译是能通过的，但是用arm-linux-gcc编译就无法通过，应该是编译起的函数库的问题。因为报错信息是关于网络协议中一个宏的定义，就好像socket中的AF_INET差不多。 编译结束后，在${PROJECT}/rootfs/下建立rootfs_1.13文件夹 并在其中建立如下路径 mkdir bin sbin lib etc dev mnt usr/bin usr/sbin usr/lib proc sys -p 并执行make install则将busybox安装 5.加入运行需要的库文件 写了一个脚本，把这个放在/usr/local/arm/3.4.1/arm-linux/lib/下执行，目的是将一些程序运行时需要的函数库复制到目标文件系统的lib路径下 ＝＝＝＝＝＝＝＝＝以下是脚本内容＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ #!/bin/bash #You should put this file cp.sh in $(CROSS-COMPILE)/lib/ ROOTFS_LIB=${PROJECT}/rootfs/rootfs_1.13/lib/ for file in libc libcrypt libdl libm libpthread libresolv libutil do cp $file-*.so ${ROOTFS_LIB} cp -d $file.so.[*0-9] ${ROOTFS_LIB} done cp -d ld*.so* ${ROOTFS_LIB} #end script ＝＝＝＝＝＝＝＝＝＝＝＝＝脚本结束＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 6.在${PROJECT}/rootfs/rootfs_1.13/etc/下建立如下文件或者路径 vi fstab 内容是： proc /proc proc defaults 0 0

JFFS2文件系统挂载过程优化的分析

JFFS2文件系统挂载过程优化的分析报告 一问题描述 在上电启动优化中发现Linux系统下挂载JFFS2文件系统耗时较长，以128M的NOR FLASH 为例，用时接近20秒。后续单板的FLASH容量为256M，时间会更长。如此长的挂载时间，会大增加系统的上电启动时间。希望能对mount功能或JFFS2文件系统做适当优化，将256M FLASH的挂载时间降到3~5秒内，优化时需要同时保证文件系统的可靠性和读写速度，要保证兼容优化前的文件系统。 root@CMM:/$ time mount -t jffs2 /dev/mtdblock1 /FLASH0 real 0m 19.83s user 0m 0.00s sys 0m 19.73s 二问题分析 与磁盘文件系统不同，JFFS2文件系统不在FLASH设备上存储文件系统结构信息，所有的信息都分散在各个数据实体节点之中，在挂载文件系统的时候，需扫描整个Flash设备，从中建立起文件系统在内存中的映像，系统在运行期间，就利用这些内存中的信息进行各种文件操作。这就造成了JFFS2文件系统挂载时间过长，尤其是FLASH比较大，文件比较多的情况下。 擦除块小结(erase block summary)补丁可以提高JFFS2文件系统的挂载速度，它最基本的思想就是用空间来换时间。具体来说，就是将擦除块每个节点的原数据信息写在这个擦除块最后的固定位置，当JFFS2挂载的时候，对每个擦除块只需要读取这个小结节点。同时该补丁具有一定的稳定性和兼容性。 ●稳定性： If the summary node is missing, maybe because of a system power-down before it could be written to flash, nothing bad happens - JFFS2 just falls back to scanning the whole block as it would have done before. ●兼容性： The JFFS2 image produced by sumtool is also usable with previous kernel because the summary node is JFFS2_FEATURE_RWCOMPAT_DELETE. （当不支持擦除块小结特性的JFFS2文件系统发现了一个属性是JFFS2_FEATURE _RWCOMPAT_DELETE的节点时，在垃圾回收的时候，该节点可以被删除） 三原理介绍

大数据技术与应用 - 大数据存储和管理 - 分布式文件系统 - 第二课

大数据技术与应用 网络与交换技术国家重点实验室 交换与智能控制研究中心 程祥 2016年9月

提纲-大数据存储和管理1. 分布式文件系统 1.1 概述 1.2 典型分布式文件系统 1.3 HDFS 2. 分布式数据库 2.1 概述 2.2 NoSQL 2.3 HBase 2.4 MongoDB（略） 2.5 云数据库（略）

1.1 概述 ?定义：相对于本地文件系统，分布式文件系统是一种通过网络实现文件在多台主机上进行分布式存储的文件系统。 ?分布式文件系统一般采用C/S模式，客户端以特定的通信协议通过网络与服务器建立连接，提出文件访问请求。 ?客户端和服务器可以通过设置访问权限来限制请求方对底层数据存储块的访问。

1.2 典型的分布式文件系统 ?NFS (Network File System) 由Sun微系统公司作为TCP/IP网上的文件共享系统开发，后移植到Linux等其他平台。其接口都已经标准化。 ?AFS (Andrew File System) 由卡耐基梅隆大学信息技术中心(ITC)开发，主要用于管理分部在不同网络节点上的文件。AFS与 NFS不同，AFS提供给用户的是一个完全透明，永远唯一的逻辑路径（NFS需要物理路径访问）。

1.2 典型的分布式文件系统（续） ?GFS（Google File System） 由Google开发，是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，并提供容错功能。 ?HDFS（Hadoop Distributed File System） HDFS是Apache Hadoop项目的一个子项目，是一个高度容错的分布式文件系统，设计用于在低成本硬件上运行，适合存储大数据，GFS的开源版本。

JFFS2文件系统分析报告

JFFS2文件系统分析报告 本文在深入研究jffs2源代码基础上，对JFFS2文件系统的实现机制进行了分析，包括关键的数据结构及其之间的联系，文件系统的注册和挂载，以及其他主要的操作流程。 1 JFFS2层次结构 在Linux系统中，JFFS2文件系统处于虚拟文件系统层VFS与存储技术设备层MTD之间,如图1所示。VFS为内核中的各种文件系统提供一个统一的抽象层，并为上层用户提供具有统一格式的接口函数；MTD子系统整合底层芯片驱动，为上层文件系统提供了统一访问MTD设备(主要是NOR闪存和NAND闪存等设备)的接口。JFFS2在内存中建立超级块信息jffs2_sb_info管理文件系统操作，建立索引节点信息jffs2_inode_info管理打开的文件。VFS层的超级块super_block和索引节点inode分别包含JFFS2文件系统的超级块信息jffs2_sb_info和索引节点信息jffs2_inode_info，它们是JFFS2和VFS间通信的主要接口。JFFS2文件系统的超级块信息jffs2_sb_info包含底层MTD设备信息mtd_info指针，文件系统通过该指针访问MTD设备，实现JFFS2和底层MTD设备驱动之间的通信。 图1 JFFS2文件系统层次 2 JFFS2数据实体 JFFS2在Flash上只存储两种类型的数据实体，分别为jffs2_raw_inode和jffs2_raw_ dirent。 ■jffs2_raw_dirent：包括文件名、ino号、父节点ino号、版本号、校验码等信息，它用来形成整个文件系统的层次目录结构。 ■jffs2_raw_inode：包括文件ino号、版本号、访问权限、修改时间、本节点所包含的数

分布式文件系统概述

分布式文件系统概述 文件系统是操作系统的一个重要组成部分，通过对操作系统所管理的存储空间的抽象，向用户提供统一的、对象化的访问接口，屏蔽对物理设备的直接操作和资源管理。 根据计算环境和所提供功能的不同，文件系统可划分为四个层次，从低到高依次是：单处理器单用户的本地文件系统，如DOS的文件系统；多处理器单用户的本地文件系统，如OS/2的文件系统；多处理器多用户的文件系统，如Unix的本地文件系统；多处理器多用户的分布式文件系统。 本地文件系统（Local File System）是指文件系统管理的物理存储资源直接连接在本地节点上，处理器通过系统总线可以直接访问。分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。上述按照层次的分类中，高层次的文件系统都是以低层次的文件系统为基础，实现了更高级的功能。比如多处理器单用户的本地文件系统需要比单处理器单用户的本地文件系统多考虑并发控制（Concurrency Control），因为可能存在多个处理器同时访问文件系统的情况；多处理器多用户的文件系统需要比多处理器单用户的本地文件系统多考虑数据安全访问方面的设计，因为多个用户存在于同一个系统中，保证数据的授权访问是一个关键；多处理器多用户的分布式文件系统需要比多处理器多用户的文件系统多考虑分布式体系结构带来的诸多问题，比如同步访问、缓冲一致性等。 随着层次的提高，文件系统在设计和实现方面的难度也会成倍提高。但是，现在的分布式文件系统一般还是保持与最基本的本地文件系统几乎相同的访问接口和对象模型，这主要是为了向用户提供向后的兼容性，同时保持原来的简单对象模型和访问接口。但这并不说明文件系统设计和实现的难度没有增加。正是由于对用户透明地改变了结构，满足用户的需求，以掩盖分布式文件操作的复杂性，才大大增加了分布式文件系统的实现难度[12]。 一、分布式文件系统的发展历史 在计算机性能不断提升的同时，计算机部件的平均价格却在不断下降。用户可以用更低的成本，购买更好、更快、更稳定的设备。存储系统、文件系统面临的新挑战也随之而来：如何管理更多的设备，提供更好的性能，更加有效地降低管理成本等。各种新的存储技术和分布式文件技术层出不穷，以满足用户日益增长的需求。以下为分布式文件系统的发展过程中的几个阶段[12]： 1980～1990年早期的分布式文件系统一般以提供标准接口的远程文件访问为目的，更多地关注访问的性能和数据的可靠性。主要以NFS和AFS(Andrew File System)最具代表性，它们对以后的文件系统设计也具有十分重要的影响。 1990～1995年20世纪90年代初，面对广域网和大容量存储应用的需求，以及当时产生的先进的高性能对称多处理器的设计思想，加利福尼亚大学设计开发的xFS，克服了以前的分布式文件系统一般都运行在局域网（LAN）上的弱点，很好地解决了在广域网上进行缓存，以减少网络流量的难题。它所采用的多层次结构很好地利用了文件系统的局部访问的特性，无效写回（Invalidation-based Write Back）缓存一致性协议，减少了网络负载。对本地主机和本地存储空间的有效利用，使它具有较好的性能。 1995～2000年在这个阶段，计算机技术和网络技术有了突飞猛进的发展，单位存储的成本大幅降低。而数据总线带宽、磁盘速度的增长无法满足应用对数据带宽的需求，存储

深入理解yaffs2文件系统(一)

深入理解yaffs2文件系统（一） 1、Flash文件系统 1.1、背景 已经有多种flash文件系统(FFSs)或flash块驱动（在之上运行一个常规的FS），同时都有优点或缺点。 Flash存储器有非常多的限制，这里就不一一列举了。已经有各种方法解决这些限制，以提供一个文件系统。必须认识到，“flash”，包括NOR和NAND，各自有不同的限制。很容易被专业术语“flash”误导，误以为用于NorFlash的方法也立即适用于NandFlash。 Nand块驱动一般采用FAT16作为文件系统，但不够健壮，也不够贴近Flash的特性。这些块驱动通过一个“本地--物理”的映射层来仿真可写的、类似于磁盘扇区的块。当使用FAT16时，这些文件系统工作的相当好，它们内存消耗小，代码尺寸也很小。但就像所有基于FAT 的系统一样，它们很容易损坏（如，丢失簇）。 其他的途径则是设计整个文件系统，不是基于块驱动，而且是flash友好的，这允许更多的余地来解决上述所提到的问题。 当前有两个linux文件系统能非常好的支持NorFLash，那就是JFFS以及它的升级版本JFFS2。这两者都提供日志机制，大大的提升了健壮性，这也是嵌入式系统特别重要的一个特性。不幸的是，它们在RAM消耗和启动时间方面都不是很好。 JFFS在flash中的每一个journalling日志节点，需要一个基于RAM的jffs_node结构，每一个节点为48字节。JFFS2做了一个大改进，通过剪裁相关的结构体（jffs2_raw_node_ref）而减少到16字节。即使如此，在512字节页大小128M的NandFlash，按平均节点大小来算，也需要250000字节约4M大小。 JFFS和JFFS2在启动时，需要扫描整个flash阵列来查找journaling节点，并决定文件结构。由于NAND容量大、慢、连续访问、需要ECC校验，这些特性将导致不可接受的、很长的启动时间。随便掐指一算，扫描128M字节的Nand阵列大小需要25秒钟。 设计yaffs2的目的就是：NandFlash友好的、通过提供日志机制达到健壮的、大大减少JFFSx 所具有的RAM消耗和启动时间。Yaffs主要是用于内部Nand而不是可移动的Nand（SM卡）。在可移动的SM智能卡，兼容性显得更重要，一般使用FAT文件系统。当然，yaffs也做了深思熟虑，认为稳定性比兼容性更重要。 1.2、Yaffs文件系统特性 YAFFS是一个专为NandFlash特性设计的文件系统。它已经被证实的好特性有： （1）fast –快速，比其他Flash文件系统要快很多。 （2）Easily ported –易于移植，已经移植到GNU/Linux，WinCE，eCOS，pSOS，VxWorks，以及其他各种系统。 （3）Log structured –日志结构，提供均衡负载，使得它非常健壮。 （4）支持多种类型的NandFlash芯片，如页大小为512B、1KB、2KB的NnadFlash等等。（5）Very fast mount –非常快速的文件系统挂载速度，几乎是立即启动的。 （6）非常少的RAM消耗。 （7）灵活的Licensing授权机制，适合许多情况。 YAFFS当前版本为v2，yaffs2除了支持512字节页大小的flash，还支持2K字节页大小的flash （YAFFS1仅仅支持原先的512字节页大小的flash）。YAFFS 1 和2已经被众多的商业产品所采用。 2、关于yaffs1文件系统

JFFS2的优缺点

JFFS2 文件系统及新特性介绍 简介：JFFS2 是一个开放源码的项目(https://www.sodocs.net/doc/7717453121.html,)。它是在闪存上使用非常广泛的读/写文件系统，在嵌入式系统中被普遍的应用。这篇文章首先分析了在闪存上使用 JFFS2 的必要性，然后详细的阐述了 JFFS2 实现的内部机制，包括日志结构的文件系统，关键的数据结构，挂载过程和垃圾收集机制。同时也指出了 JFFS2 的局限性，并介绍了最新的针对 JFFS2 的不足进行改进的补丁程序。最后对 JFFS3 的设计思想和现在的开发状况给予了简单的介绍。 1．为什么需要 JFFS2 这一小节首先介绍了闪存相对于磁盘介质的特别之处，然后分析了将磁盘文件系统运行在闪存上的不足，同时也给出了我们使用 JFFS2 的理由。 1.1 闪存(Flash Memory) 的特性和限制 这里所介绍的闪存的特性和限制都是从上层的文件系统的角度来看的，而不会涉及到具体的物理特性。总的来说，有两种类型的 flash memory: NOR flash 和NAND flash. 先介绍一下这两种闪存所具有的共同特性。 A) 闪存的最小寻址单位是字节(byte)，而不是磁盘上的扇区(sector)。这意味着我们可以从一块闪存的任意偏移(offset)读数据，但并不表明对闪存写操作也是以字节为单位进行的。我们会在下面的阐述中找到答案。 B) 当一块闪存处在干净的状态时（被擦写过，但是还没有写操作发生），在这块flash上的每一位(bit)都是逻辑1。 C) 闪存上的每一位(bit)可以被写操作置成逻辑0。可是把逻辑 0 置成逻辑 1 却不能按位(bit)来操作，而只能按擦写块（erase block）为单位进行擦写操作。擦写块的大小从 4K 到128K 不等。从上层来看，擦写所完成的功能就是把擦写块内的每一位都重设置（reset）成逻辑 1。 D) 闪存的使用寿命是有限的。具体来说，闪存的使用寿命是由擦写块的最大可擦写次数来决定的。超过了最大可擦写次数，这个擦写块就成为坏块(bad block)了。因此为了避免某个擦写块被过度擦写，以至于它先于其他的擦写块达到最大可擦写次数，我们应该在尽量小的影响性能的前提下，使擦写操作均匀的分布在每个擦写块上。这个过程叫做磨损平衡（wear leveling）。 NOR flash 与 NAND flash 的不同之处： A) NOR flash 读/写操作的基本单位是字节；而 NAND flash 又把擦写块分成页(page), 页是写操作的基本单位，一般一个页的大小是 512 或 2K 个字节。对于一个页的重复写操作次数是有限制的，不同厂商生产的 NAND flash 有不同的限制，有些是一次，有些是四次，六次或十次。