时光荏苒..
全部博文（453）
分类： LINUX
2012-01-13 19:33:22
scale [skeil] 比例 扩容
UBIFS不是运行在block device之上的（比如hard disk, MMC/SD卡，USB flash驱动等等)
FTL--在flash hardware上模拟一个block device 块设备
UBIFS 工作在裸flash上，即没有controller device，也不含FTL，直接工作在擦写块上
UBIFS文件系统的所有数据结构都是使用tree，所以 UBIFS对flash尺寸算法上是可扩展的。然而，UBI对于flash size是线性增长的，因此UBI/UBIFS stack空间整体上是线性增大的。但是UBIFS的作者认为可以创建一个新的UBI2，克服当前UBI的线性。当前的UBI适应2~16GiB大小的raw flashes, 具体依赖与I/O速度和需求。
注意，尽管UBI是线性增长的，但是它的可扩展性依然好过JFFS2，因为JFFS2最初是为32MiB Nor flashes设计的。JFFS2的扩展性是文件系统级的，而UBI/UBIFS的扩展性则是raw flash级的，下表是两个文件系统扩展性的对比。
Write-back support
UBIFS支持write-back, 意味着文件的改变并不是立刻提交到flash media上，而是cache这些修改，直到达到写入的条件。这减少了I/O的数目因此改善I/O性能和系统性能。回写本身也是文件系统的标准技术，由于数据没有立刻写入flash, 回写带来了数据丢失的风险。
相反, JFFS2不支持write-back, JFFS2文件系统的所有变化都是立刻同步到flash介质上。事实上，JFFS2有一个很小的buffer大小是NAND page size（如果是 NAND flash）。这个buffer保存这最后要写的数据，一旦buffer写满立刻就会执行flush。 因此JFFS2非常类似于同步文件系统。
write-back支持，需要应用程序注意及时同步重要的文件。否则掉电会导致这些文件的损坏和消失，掉电对于嵌入式系统而言是很常见的。
然而一些应用空间程序并没有考虑write-back这种情况。当这些应用运行在JFFS2上工作良好尽管这些应用是buggy的，一旦运行在UBIFS上，bugs就很容易重现了。在把JFFS2换作UBIFS后，确保检查你的应用是否正确处理掉电功能。下列是检查列表以及一些建议：
1. 如果你想切换到同步模式，在mount文件系统是使用 -o 同步选项。然而，要注意文件系统将会下降。此外，要记住UBIFS mount为同步模式仍然不如JFFS2提供更多的保证
2. 一定要时刻记住运行fsync在你修改重要数据后；当然，没有必要sync临时的文件；要先考虑文件数据的重要性，不要执行没必要的fsync，因为fsync操作会降低性能
3. 如果你想更精确些，那么就使用fdatasync，仅仅修改的数据被flushed，而inode meta-data变化不会被flush(比如mtime或者permissions)。
4. 你也可以在open()调用时使用O_SYNC标志；这使得这个文件所修改的data(不包括meta-data)都会在write()操作返回前写入media；通常来说，最好使用fsync()，因为O_SYNC使得每个写都是同步的，而fsync允许多个累积的写。
5. 还可以使一定数目inodes为同步模式，通过设置inode的sync标志； 在shell中执行chattr +S；在C程序中，则可以使用FS_IOC_SETFLAGS ioctl命令； 注意，mkfs.ubifs工具会检查原始的FS树，如果文件在原始文件树是同步的，那么在UBIFS image也会是同步的。
要强调的是，上面的方法对于任何文件系统都是可行的(通用，适用性)，包括JFFS2。
fsync()可能包括目录 - 它同步目录inode的meta-data。 “sync” flag也可以用在目录上，使得目录inode变成同步的。但是"sync" flag是可继承的， 意味这这个目录下的所有新节点都有这个标志。 这个目录的新文件和新子目录也就变成同步的， 子目录的child也是如此。 这个功能对于创建一个整个目录树都同步的目录是很有用的。
fdatasync()调用对 UBIFS的目录是不起作用的， 因为UBIFS对目录项的操作都是同步的，当然不是所有文件系统都如此。类似的， "dirsync" inode 标志对UBIFS没有作用
以上提到的功能都是作用于文件描述符，而不是stream（FILE *）。同步一个stream，你应该通过libc的fileno()取得文件描述符， 首先使用fflush()来flush stream ，然后调用fsync或者fdatasync. 你也可以使用其他的同步方法，但是记得在同步文件前要先flush stream. fflush() 和sync()，fsync，fdatasync与前者的区别，在于前者仅仅同步libc-level的buffer，而后者则是同步kernel-level buffers。
Linux有几个内核参数可以用来调整write-back，可查看/proc/sys/vm. 这些参数是global, 所以会影响所有的文件系统。 参考Documentation/sysctl/vm.txt获取更多的信息。
1. dirty_writeback_centisecs: linux周期性write-back线程写出dirty数据的周期，这个机制可以确保所有的脏数据在某个时间点都可以写入介质。
2. dirty_expire_centisecs: dirty数据的过期周期，这是数据为dirty的最大时间。 过了这个时间，dirty数据会被周期性write-back线程写回介质。换句话说，周期性write-back线程每dirty-writeback-centisecs 时间唤醒，然后同步那些dirty_expire_centisecs时间之前就已经dirty的数据。
3. dity_background_ratio: dirty数据与全部内存的最大百分比。 当脏数据变多的时候，周期性的write-back线程开始同步数据使得脏数据比例变小。这个过程包括那些non-expired的数据。 这个可以认为是系统dirty数据的soft limit。
4. dirty_ratio: dirty数据与全部内存的最大百分比，超过这个显示，writes同步数据先于增加dirty数据。这个是系统diry 数据的hard limit。
UBIFS是一个异步文件系统，和其他文件系统一样，UBIFS也利用了page cache。page cache是一个通用的linux内存管理机制，page cache可以非常大以cache更多的数据。当你写一个文件时，首先写到page cache中，置为dirty，然后write操作返回（同步的文件是例外）。以后数据会通过write-back机制写回。
write-buffer是UBIFS特定的buffer, 它位于page cache和flash介质之间。这意味着write-back actually writes to the write-buffer, not directly to the flash。
write-buffer 是用来优化UBIFS在NAND flashes上的速度。NAND flashes包含NAND pages，页是NAND flash的最小读写单位，通常为512 2KiB或者4KiB。
The write-buffer is designated to speed-up UBIFS on NAND flashes. NAND flashes consist of由组成 NAND pages, which are usually 512, 2KiB or 4KiB in size. NAND page is the minimal最小的 read/write unit of NAND flash。
write-buffer尺寸等于NAND page size. 他的目的是积累samll writes，and write full NAND pages instead of partially filled。考虑下面的例子，假定在半秒内写了4 512bytes nodes，page size是2kiB的情况下。如果没有write-buffer，那么分开的写会使用4个NAND page，浪费6KiB的空间，而write-buffer 可以仅写一次，并且没有空间浪费。这意味着，write-buffer避免生成过多的dirty space，UBIFS的垃圾收集所做的工作就越少。
当然上面的例子是一个理想状态，即便write-buffer也可能浪费空间，比如使用同步I/O或者数据抵达的时间间隔较大。因为write-buffer也有个过期时间，每3-5秒即便write-buffer不满，也会写出。这是为了数据完整性的原因。
当然，如果UBIFS写大量的数据，那么就不使用write-buffer。仅仅数据的最后一部分由于小于NAND page尺寸需要等待填满page的数据，直到write-buffer的定时器到时。
write-buffer实现上有一点复杂，UBIFS中使用了一些write-buffer，每个journal head都有一个。 当然这并不改变write-buffer的基本机制。
关于同步有几点需要注意的：
1. sycn()会同步所有的write-buffers
2. fsync(fd)也会同步 fd相关的所有write-buffers
3. 用O_SYNC打开文件，会忽略write-buffers, 所以I/O会直接写入介质
4. 如果文件系统mount时使用了-o sync选项，那么write-buffers也会被忽略
在数据同步时要考虑write-buffer的timer时间，在synchronization timout "dirty_expire_centisecs"加上额外的3-5秒，当然由于write-buffer很小，所以delay的数据很少。
FTL stands for "Flash Translation Layer" and it is software which emulates a block device on top of flash hardware.在flash hardware上模拟一个block device。 At early days FTL ran on the host computer. So the host computer had to run the FTL software driver which implemented PCMCIA FTL. However, nowadays FTL is usually firmware, and it is run by the controller which is built into the storage device.今天FTL通常都是fireware, 运行在存储设备内建的控制器上。 For example, if you look inside an USB flash drive, you'll find there a NAND chip (or several of them), and a micro-controller, which runs FTL firmware. Some USB flash drives are known to have quite powerful ARM processors inside. Similarly, MMC, eMMC, SD, SSD, and other FTL devices have a built-in controller which runs FTL firmware.
UBIFS file system has been designed for raw flash裸的 没有controller，当然也就没有了FTL firmware. It doesn't work with block devices and it assumes the raw flash device model. In other words, it assumes the device has eraseblocks, 他无法工作在block device之上。换句话说，它认为设备有很多eraseblocks。 which may be written to, read from, or erased. UBIFS takes care of writing all data out-of-place, doing garbage-collection and so on. UBIFS utilizes UBI, which is doing stuff like wear-leveling and bad eraseblock handling. All these things are not normally needed for block devices.
Very often people ask questions like "why would one need to use raw flash and why not just use eMMC, or something like this?". Well, there is no simple answer, and the following is what UBIFS developers think. Please, take into account the date of this writing (3 May 2009). The answer is given in form of a list of non-structured items, and the reader should structure it in a way which is appropriate for his system. And because mass storage systems mostly use NAND flash (modern FTL devices also have NAND flash arrays inside), we talk specifically about NAND flashes. Also, we'd like to emphasize that we do not give general recommendations and everything depends on system requirements.
