--- /dev/null
+=========================================================
+¤³¤ì¤Ï¡¢
+Linux-3.3/Documentation/filesystems/logfs.txt ¤ÎÏÂÌõ¤Ç¤¹¡£
+ËÝÌõÃÄÂΡ§ JF ¥×¥í¥¸¥§¥¯¥È < http://www.linux.or.jp/JF/ >
+¹¹¿·Æü ¡§ 2012/5/31
+ËÝÌõ¼Ô ¡§ Seiji Kaneko < skaneko at mbn dot or dot jp >
+=========================================================
+
+#The LogFS Flash Filesystem
+#==========================
+LogFS ¥Õ¥é¥Ã¥·¥å¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à
+================================
+
+#Specification
+#=============
+»ÅÍÍ
+====
+
+#Superblocks
+#-----------
+¥¹¡¼¥Ñ¡¼¥Ö¥í¥Ã¥¯
+----------------
+
+#Two superblocks exist at the beginning and end of the filesystem.
+#Each superblock is 256 Bytes large, with another 3840 Bytes reserved
+#for future purposes, making a total of 4096 Bytes.
+¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤ÎºÇ½é¤ÈºÇ¸å¤Ë¡¢³Æ°ì¤Ä¤Î¥¹¡¼¥Ñ¡¼¥Ö¥í¥Ã¥¯ (¹ç·× 2 ¸Ä)¤¬¤¢¤ê
+¤Þ¤¹¡£¤¤¤º¤ì¤â 256 ¥Ð¥¤¥È¤ÎŤµ¤Ç¡¢¾Íè¤Î³ÈÄ¥¤Î¤¿¤á 3840 ¥Ð¥¤¥È¤¬¥ê¥¶¡¼¥Ö¤µ
+¤ì¤Æ¤¤¤ë¤¿¤á¡¢¹ç¤ï¤»¤Æ 4096 ¥Ð¥¤¥È¤Ë¤Ê¤ê¤Þ¤¹¡£
+
+#Superblock locations may differ for MTD and block devices. On MTD the
+#first non-bad block contains a superblock in the first 4096 Bytes and
+#the last non-bad block contains a superblock in the last 4096 Bytes.
+#On block devices, the first 4096 Bytes of the device contain the first
+#superblock and the last aligned 4096 Byte-block contains the second
+#superblock.
+¥¹¡¼¥Ñ¡¼¥Ö¥í¥Ã¥¯¤Î°ÌÃ֤ϡ¢MTD ¤È¥Ö¥í¥Ã¥¯¥Ç¥Ð¥¤¥¹¤Ç°Û¤Ê¤ë²ÄǽÀ¤¬¤¢¤ê¤Þ¤¹¡£
+MTD ¤Î¾ì¹ç¡¢ºÇ½é¤ÎÉÔÎɤÎ̵¤¤¥Ö¥í¥Ã¥¯¤ËºÇ½é¤Î 4096 ¥Ð¥¤¥È¤Î¥¹¡¼¥Ñ¡¼¥Ö¥í¥Ã¥¯
+¤¬¡¢¤½¤·¤ÆºÇ¸å¤ÎÉÔÎɤÎ̵¤¤¥¹¡¼¥Ñ¡¼¥Ö¥í¥Ã¥¯¤ËºÇ¸å¤Î 4096 ¥Ð¥¤¥Èʬ¤¬³ÊǼ¤µ¤ì
+¤Þ¤¹¡£¥Ö¥í¥Ã¥¯¥Ç¥Ð¥¤¥¹¤Ç¤Ï¡¢¥Ç¥Ð¥¤¥¹¤ÎºÇ½é¤Î 4096 ¥Ð¥¤¥È¤ËºÇ½é¤Î¥¹¡¼¥Ñ¡¼¥Ö
+¥í¥Ã¥¯¤¬¡¢¤½¤·¤ÆºÇ¸å¤Î¥¢¥é¥¤¥ó¤µ¤ì¤¿ 4096 ¥Ð¥¤¥È¤Î¥Ö¥í¥Ã¥¯¤ËÆóÈÖÌܤΥ¹¡¼¥Ñ
+¡¼¥Ö¥í¥Ã¥¯¤¬³ÊǼ¤µ¤ì¤Þ¤¹¡£
+
+#For the most part, the superblocks can be considered read-only. They
+#are written only to correct errors detected within the superblocks,
+#move the journal and change the filesystem parameters through tunefs.
+#As a result, the superblock does not contain any fields that require
+#constant updates, like the amount of free space, etc.
+Ëؤɤξì¹ç¡¢¥¹¡¼¥Ñ¡¼¥Ö¥í¥Ã¥¯¤ÏÆɤ߽Ф·ÀìÍѤȤ·¤Æ°·¤ï¤ì¤Þ¤¹¡£¥¹¡¼¥Ñ¡¼¥Ö¥í¥Ã
+¥¯¤Ï¡¢¥Ö¥í¥Ã¥¯Æâ¤Ç¥¨¥é¡¼¤¬È¯¸«¤µ¤ì¤¿¾ì¹ç¤ÎÄûÀµ»þ¡¢¥¸¥ã¡¼¥Ê¥ë¤Î°ÜÆ°¡¢¤½¤·¤Æ
+tunefs ¤Ë¤è¤ë¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¥Ñ¥é¥á¡¼¥¿¤ÎÊѹ¹»þ¤Ç¤Î¤ß½ñ¤¹þ¤Þ¤ì¤Þ¤¹¡£¤³¤Î
+·ë²Ì¡¢¥¹¡¼¥Ñ¡¼¥Ö¥í¥Ã¥¯¤Ë¤Ï¶õ¤ÍÆÎ̤ʤɤÎÄê¾ïŪ¤Ë¹¹¿·¤¬¹Ô¤ï¤ì¤ë¥Õ¥£¡¼¥ë¥É¤Ï
+´Þ¤Þ¤ì¤Þ¤»¤ó¡£
+
+#Segments
+#--------
+¥»¥°¥á¥ó¥È
+----------
+
+#The space in the device is split up into equal-sized segments.
+#Segments are the primary write unit of LogFS. Within each segments,
+#writes happen from front (low addresses) to back (high addresses. If
+#only a partial segment has been written, the segment number, the
+#current position within and optionally a write buffer are stored in
+#the journal.
+¥Ç¥Ð¥¤¥¹¶õ´Ö¤Ï¡¢Æ±¤¸Â礤µ¤Î¥»¥°¥á¥ó¥È¤Ëʬ³ä¤µ¤ì¤Æ¤¤¤Þ¤¹¡£¥»¥°¥á¥ó¥È¤Ï
+LogFS ¤Ç¤Î´ðËÜŪ¤Ê½ñ¤¹þ¤ßñ°Ì¤Ç¤¹¡£³Æ¥»¥°¥á¥ó¥È¤Ç¤Ï¡¢½ñ¤¹þ¤ß¤ÏºÇ½é (Äã
+°Ì¥¢¥É¥ì¥¹) ¤«¤éºÇ¸å (¹â°Ì¥¢¥É¥ì¥¹) ¤ÎÊý¸þ¤Ë¸þ¤«¤Ã¤Æ¹Ô¤ï¤ì¤Þ¤¹¡£¥»¥°¥á¥ó
+¥È¤Î°ìÉô¤Î¤ß¤¬½ñ¤¹þ¤Þ¤ì¤ë¾ì¹ç¡¢¥»¥°¥á¥ó¥ÈÈֹ桢¥»¥°¥á¥ó¥ÈÆâ¤ÎºÇ½ª½ñ¤¹þ
+¤ß°ÌÃÖ¡¢¥ª¥×¥·¥ç¥ó¤È¤·¤Æ½ñ¤¹þ¤ß¥Ð¥Ã¥Õ¥¡¤Î»°¤Ä¤¬¥¸¥ã¡¼¥Ê¥ë¤ËÊݸ¤µ¤ì¤Þ¤¹¡£
+
+#Segments are erased as a whole. Therefore Garbage Collection may be
+#required to completely free a segment before doing so.
+¥»¥°¥á¥ó¥È¤Ï¡¢¥»¥°¥á¥ó¥Èñ°Ì¤Ç¾Ãµî¤µ¤ì¤Þ¤¹¡£¤³¤Î¤¿¤á¡¢¾Ãµî¤ÎÁ°¤Ë¤Ï¥»¥°¥á¥ó
+¥È¤ò´°Á´¤Ë¶õ¤¤Ë¤¹¤ë¤¿¤á¤Î¥¬¥Ù¡¼¥¸¥³¥ì¥¯¥·¥ç¥ó¤¬É¬Íפˤʤê¤Þ¤¹¡£
+
+#Journal
+#--------
+¥¸¥ã¡¼¥Ê¥ë
+----------
+
+#The journal contains all global information about the filesystem that
+#is subject to frequent change. At mount time, it has to be scanned
+#for the most recent commit entry, which contains a list of pointers to
+#all currently valid entries.
+¥¸¥ã¡¼¥Ê¥ë¤Ë¤Ï¡¢¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤ÎÉÑÈˤËÊѹ¹¤µ¤ì¤ë¥°¥í¡¼¥Ð¥ë¾ðÊ󤹤٤Ƥ¬
+³ÊǼ¤µ¤ì¤Þ¤¹¡£¥Þ¥¦¥ó¥È»þ¤Ë¡¢¥¸¥ã¡¼¥Ê¥ë¤ò¥¹¥¥ã¥ó¤·¤ÆºÇ¸å¤Ë¥³¥ß¥Ã¥È¤µ¤ì¤¿
+¥¨¥ó¥È¥ê¤ò¼èÆÀ¤¹¤ëɬÍפ¬Í¤ê¤Þ¤¹¡£¤³¤Î¥¨¥ó¥È¥ê¤Ë¤Ï¡¢¸½ºß͸ú¤ÊÁ´¤Æ¤Î¥¨¥ó
+¥È¥ê¤Ø¤Î¥Ý¥¤¥ó¥¿¤Î¥ê¥¹¥È¤¬³ÊǼ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
+
+#Object Store
+#------------
+¥ª¥Ö¥¸¥§¥¯¥È¥¹¥È¥¢
+------------------
+
+#All space except for the superblocks and journal is part of the object
+#store. Each segment contains a segment header and a number of
+#objects, each consisting of the object header and the payload.
+#Objects are either inodes, directory entries (dentries), file data
+#blocks or indirect blocks.
+¥¹¡¼¥Ñ¡¼¥Ö¥í¥Ã¥¯¤È¥¸¥ã¡¼¥Ê¥ë°Ê³°¤ÎÎΰè¤Ï¡¢¥ª¥Ö¥¸¥§¥¯¥È¥¹¥È¥¢Éô¤Ë¤Ê¤ê¤Þ¤¹¡£
+³Æ¥»¥°¥á¥ó¥È¤Ï¥»¥°¥á¥ó¥È¥Ø¥Ã¥À¤ÈÊ£¿ô¤Î¥ª¥Ö¥¸¥§¥¯¥È¤ò´Þ¤ß¤Þ¤¹¡£¤Þ¤¿¡¢³Æ¥ª
+¥Ö¥¸¥§¥¯¥È¤Ï¥ª¥Ö¥¸¥§¥¯¥È¥Ø¥Ã¥À¤È¥Ú¥¤¥í¡¼¥É¤«¤é¤Ê¤ê¤Þ¤¹¡£¥ª¥Ö¥¸¥§¥¯¥È¤Ï¡¢
+inode ¤«¡¢¥Ç¥£¥ì¥¯¥È¥ê¥¨¥ó¥È¥ê (dentry) ¤«¡¢¥Õ¥¡¥¤¥ë¥Ç¡¼¥¿¥Ö¥í¥Ã¥¯¤«¡¢´Ö
+ÀÜ»²¾È¥Ö¥í¥Ã¥¯¤«¤Î²¿¤ì¤«¤Ç¤¹¡£
+
+#Levels
+#------
+¥ì¥Ù¥ë
+------
+
+#Garbage collection (GC) may fail if all data is written
+#indiscriminately. One requirement of GC is that data is separated
+#roughly according to the distance between the tree root and the data.
+#Effectively that means all file data is on level 0, indirect blocks
+#are on levels 1, 2, 3 4 or 5 for 1x, 2x, 3x, 4x or 5x indirect blocks,
+#respectively. Inode file data is on level 6 for the inodes and 7-11
+#for indirect blocks.
+Á´¤Æ¤Î¥Ç¡¼¥¿¤¬¤¤¤¤¢¤¿¤ê¤Ð¤Ã¤¿¤ê¤Ë½ñ¤«¤ì¤Æ¤¤¤¿¾ì¹ç¡¢¥¬¥Ù¡¼¥¸¥³¥ì¥¯¥·¥ç¥ó
+(GC) ¤¬¼ºÇÔ¤¹¤ë²ÄǽÀ¤¬½Ð¤Æ¤¤Þ¤¹¡£GC Æ°ºî¤ÎɬÍ×¾ò·ï¤Î°ì¤Ä¤Ï¡¢¥Ç¡¼¥¿¤¬¥Ä
+¥ê¡¼¤Î¥ë¡¼¥È¤È¥Ç¡¼¥¿¤Þ¤Ç¤Îµ÷Î¥¤Ë½¾¤Ã¤ÆÂ绨ÇĤËʬ»¶ÇÛÃÖ¤µ¤ì¤Æ¤¤¤ë¤³¤È¤Ç¤¹¡£
+¤³¤ì¤Ï¡¢¼Â¸úŪ¤Ë¤Ï¡¢Á´¤Æ¤Î¥Õ¥¡¥¤¥ë¥Ç¡¼¥¿¤¬¥ì¥Ù¥ë 0 ¤Ë¤¢¤Ã¤¿¾ì¹ç¡¢1x, 2x,
+3x, 4x, 5x ¤Î´ÖÀÜ¥Ö¥í¥Ã¥¯¤ËÂФ·¤Æ¥ì¥Ù¥ë 1, 2, 3, 4, 5 ¤Î´ÖÀÜ¥Ö¥í¥Ã¥¯¤¬½ç
+¤ËÂбþ¤¹¤ë¤È¤¤¤¦¤³¤È¤Ç¤¹¡£Inode ¥Õ¥¡¥¤¥ë¥Ç¡¼¥¿¤Ï inode ¤Î¥ì¥Ù¥ë 6 ¤ËÃÖ¤«
+¤ì¡¢7-11 ¤¬´ÖÀÜ¥Ö¥í¥Ã¥¯¸þ¤±¤Ë¤Ê¤ê¤Þ¤¹¡£
+
+#Each segment contains objects of a single level only. As a result,
+#each level requires its own separate segment to be open for writing.
+³Æ¥»¥°¥á¥ó¥È¤Ë¤Ïñ°ì¤Î¥ì¥Ù¥ë¤Î¥ª¥Ö¥¸¥§¥¯¥È¤Î¤ß¤¬³ÊǼ¤µ¤ì¤Þ¤¹¡£¤³¤Î·ë²Ì¡¢
+½ñ¤¹þ¤ß¤Ëȼ¤¦¥ª¡¼¥×¥ó¤Î¤¿¤á¤Ë¤Ï¡¢³Æ¥ì¥Ù¥ë¤ÇÀìÍѤΥ»¥°¥á¥ó¥È¤¬É¬Íפˤʤê
+¤Þ¤¹¡£
+
+#Inode File
+#----------
+Inode ¥Õ¥¡¥¤¥ë
+--------------
+
+#All inodes are stored in a special file, the inode file. Single
+#exception is the inode file's inode (master inode) which for obvious
+#reasons is stored in the journal instead. Instead of data blocks, the
+#leaf nodes of the inode files are inodes.
+inode ¤ÏÁ´¤Æ inode ¥Õ¥¡¥¤¥ë¤È¤¤¤¦ÆÃÊ̤Υե¡¥¤¥ë¤Ë³ÊǼ¤µ¤ì¤Þ¤¹¡£¤¿¤À°ì¤Ä¤Î
+Îã³°¤Ï¡¢inode ¥Õ¥¡¥¤¥ë¤Î inode (¥Þ¥¹¥¿ inode) ¤Ç¡¢¤³¤ì¤ÏÍýͳ¤Ï¤¢¤¤é¤«¤È
+»×¤¤¤Þ¤¹¤¬¥¸¥ã¡¼¥Ê¥ë¤Ë³ÊǼ¤µ¤ì¤Þ¤¹¡£¥Ç¡¼¥¿¥Ö¥í¥Ã¥¯¤Î¾ì¹ç¤È¤Ï°Û¤Ê¤ê¡¢inode
+¥Õ¥¡¥¤¥ë¤Î¥ê¡¼¥Õ¥Î¡¼¥É¤Ï inode ¤Ë¤Ê¤ê¤Þ¤¹¡£
+
+#Aliases
+#-------
+¥¨¥¤¥ê¥¢¥¹
+----------
+
+#Writes in LogFS are done by means of a wandering tree. A na\8f«Áve
+#implementation would require that for each write or a block, all
+#parent blocks are written as well, since the block pointers have
+#changed. Such an implementation would not be very efficient.
+LogFS ¤Ø¤Î½ñ¤¹þ¤ß¤Ï¡¢¥Ä¥ê¡¼¤Îõº÷¤Ë¤è¤Ã¤Æ¹Ô¤ï¤ì¤Þ¤¹¡£ÁÇËѤʼÂÁõ¤À¤È°ì¤Ä
+¤Î¥Ö¥í¥Ã¥¯¤Î½ñ¤¹þ¤ßËè¤Ë¤³¤Îõº÷¤¬É¬Íפˤʤꡢ¤µ¤é¤Ë¥Ö¥í¥Ã¥¯¥Ý¥¤¥ó¥¿¤¬ÊÑ
+¹¹¤µ¤ì¤ë¤¿¤áÁ´¤Æ¤Î¿Æ¥Ö¥í¥Ã¥¯¤Ø¤Î½ñ¤¹þ¤ß¤â¹Ô¤ï¤ì¤Þ¤¹¡£¤³¤Î¤è¤¦¤Ê¼ÂÁõ¤Ï¤È
+¤Æ¤â¸úΨŪ¤È¤Ï¸À¤¨¤Þ¤»¤ó¡£
+
+#In LogFS, the block pointer changes are cached in the journal by means
+#of alias entries. Each alias consists of its logical address - inode
+#number, block index, level and child number (index into block) - and
+#the changed data. Any 8-byte word can be changes in this manner.
+LogFS ¤Ç¤Ï¡¢¥Ö¥í¥Ã¥¯¥Ý¥¤¥ó¥¿¤Î¹¹¿·¤Ï¥¨¥¤¥ê¥¢¥¹¥¨¥ó¥È¥ê¤È¤·¤Æ¥¸¥ã¡¼¥Ê¥ë¤Ë
+¥¥ã¥Ã¥·¥å¤µ¤ì¤Þ¤¹¡£³Æ¥¨¥¤¥ê¥¢¥¹¤Ë¤ÏÏÀÍý¥¢¥É¥ì¥¹ (inode Èֹ桢¥Ö¥í¥Ã¥¯¥¤
+¥ó¥Ç¥Ã¥¯¥¹¡¢¥ì¥Ù¥ë¤È»ÒÈÖ¹æ (¥Ö¥í¥Ã¥¯¤Ø¤Î¥¤¥ó¥Ç¥Ã¥¯¥¹)) ¤È¡¢¹¹¿·¥Ç¡¼¥¿¤¬³Ê
+Ǽ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£³Æ 8 ¥Ð¥¤¥È (1 ¥ï¡¼¥É) ¤Ï¡¢¤³¤Î¤è¤¦¤ÊÆâÍƤÎÊѹ¹¤Ç¤¢¤ë²Äǽ
+À¤¬¤¢¤ê¤Þ¤¹¡£
+<!-- TODO ¡© -->
+
+#Currently aliases are used for block pointers, file size, file used
+#bytes and the height of an inodes indirect tree.
+¸½ºß¡¢¥Ö¥í¥Ã¥¯¥Ý¥¤¥ó¥¿¡¢¥Õ¥¡¥¤¥ë¥µ¥¤¥º¡¢¥Õ¥¡¥¤¥ë¤Î»È¤Ã¤Æ¤¤¤ë¥Ð¥¤¥È¿ô¡¢
+inode ¤Î´ÖÀܥĥ꡼¤Î¿¼¤µ¥Ç¡¼¥¿¤Î³ÊǼ¤Ë¥¨¥¤¥ê¥¢¥¹¤¬ÍѤ¤¤é¤ì¤Æ¤¤¤Þ¤¹¡£
+
+#Segment Aliases
+#---------------
+¥»¥°¥á¥ó¥È¥¨¥¤¥ê¥¢¥¹
+--------------------
+
+#Related to regular aliases, these are used to handle bad blocks.
+#Initially, bad blocks are handled by moving the affected segment
+#content to a spare segment and noting this move in the journal with a
+#segment alias, a simple (to, from) tupel. GC will later empty this
+#segment and the alias can be removed again. This is used on MTD only.
+Ä̾ï¤Î¥¨¥¤¥ê¥¢¥¹¤È¤è¤¯»÷¤Æ¤¤¤Þ¤¹¤¬¡¢¤³¤ì¤é¤Ï¥Ð¥Ã¥É¥Ö¥í¥Ã¥¯½èÍý¤ÇÍѤ¤¤Þ¤¹¡£
+¥Ð¥Ã¥É¥Ö¥í¥Ã¥¯¤ò¸«¤Ä¤±¤¿¾ì¹ç¡¢ÌäÂê¤Î¤¢¤ë¥»¥°¥á¥ó¥È¤¬¥¹¥Ú¥¢¥»¥°¥á¥ó¥È¤Ë°Ü
+Æ°¤µ¤ì¡¢°ÜÆ°¤·¤¿¤³¤È¤¬¥»¥°¥á¥ó¥È¥¨¥¤¥ê¥¢¥¹¤È¤·¤Æ¡¢Ã±½ã¤Ê¥¿¥×¥ë (°ÜÆ°¸µ¡¢
+°ÜÆ°Àè) ·Á¼°¤Ç¥¸¥ã¡¼¥Ê¥ë¤ËµÏ¿¤µ¤ì¤Þ¤¹¡£¤½¤Î¤Î¤Á GC ¤¬¤³¤Î¥»¥°¥á¥ó¥È¤ò¶õ
+¤Ë¤·¡¢¥¨¥¤¥ê¥¢¥¹¤ÏºÆÅÙºï½ü²Äǽ¤Ë¤Ê¤ê¤Þ¤¹¡£¤³¤Îµ¡Ç½¤Ï MTD ¤Ç¤Î¤ß»ÈÍѤ·¤Þ¤¹¡£
+
+#Vim
+#---
+Vim
+---
+
+#By cleverly predicting the life time of data, it is possible to
+#separate long-living data from short-living data and thereby reduce
+#the GC overhead later. Each type of distinc life expectency (vim) can
+#have a separate segment open for writing. Each (level, vim) tupel can
+#be open just once. If an open segment with unknown vim is encountered
+#at mount time, it is closed and ignored henceforth.
+¥Ç¡¼¥¿¤Î¼÷Ì¿¤ò¸¤¯Í½Â¬¤¹¤ë¤³¤È¤Ë¤è¤ê¡¢Ä¹´ü¤Î¼÷Ì¿¤ò»ý¤Ä¥Ç¡¼¥¿¤Èû´ü¤Î¼÷Ì¿
+¤·¤«»ý¤¿¤Ê¤¤¥Ç¡¼¥¿¤È¤ò¶èÊ̤·¡¢¤½¤Î·ë²Ì¸å¤Ç¤Î GC ¥ª¡¼¥Ð¥Ø¥Ã¥É¤òºï¸º¤¹¤ë¤³
+¤È¤¬²Äǽ¤Ë¤Ê¤ê¤Þ¤¹¡£¸Ä¡¹¤Îͽ¬¼÷Ì¿ (vim) ¥¿¥¤¥×¤ÏÆÈΩ¤Î¥»¥°¥á¥ó¥È¤ò»ý¤Á¡¢
+½ñ¤¹þ¤ß²Äǽ¤Ç¤¹¡£³Æ ¥ì¥Ù¥ë/vim ¥¿¥×¥ë¤Ï°ì²ó¤À¤±¥ª¡¼¥×¥ó²Äǽ¤Ç¤¹¡£¥Þ¥¦¥ó
+¥È»þ¤Ë vim ¤ÎÉÔÌÀ¤Ê³«¤«¤ì¤¿¥»¥°¥á¥ó¥È¤ò¸«¤Ä¤±¤¿¾ì¹ç¡¢¤½¤ì¤ÏÊĤ¸¤é¤ì¤Æ°Ê¹ß
+̵»ë¤µ¤ì¤Þ¤¹¡£
+
+#Indirect Tree
+#-------------
+´ÖÀܥĥ꡼
+----------
+
+#Inodes in LogFS are similar to FFS-style filesystems with direct and
+#indirect block pointers. One difference is that LogFS uses a single
+#indirect pointer that can be either a 1x, 2x, etc. indirect pointer.
+#A height field in the inode defines the height of the indirect tree
+#and thereby the indirection of the pointer.
+LogFS ¤Î inode ¤Ï FFS ¤Ë»÷¤¿¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤Ç¡¢Ä¾ÀÜ¥Ö¥í¥Ã¥¯¥Ý¥¤¥ó¥¿¤È´Ö
+ÀÜ¥Ö¥í¥Ã¥¯¥Ý¥¤¥ó¥¿¤ò¤â¤Ã¤Æ¤¤¤Þ¤¹¡£°ì¤Ä¤Î°ã¤¤¤Ï¡¢LogFS ¤Ç¤Ï°ì¤Ä¤Î´ÖÀܥݥ¤
+¥ó¥¿¤¬ 1x 2x ¤Ê¤É¤Î´ÖÀܥݥ¤¥ó¥¿¤È¤Ê¤ê¤¦¤ëÅÀ¤¬°Û¤Ê¤ê¤Þ¤¹¡£inode ¤Î height
+¥Õ¥£¡¼¥ë¥É¤Ï´ÖÀܥĥ꡼¤Î¿¼¤µ¡¢¤Ä¤Þ¤ê¥Ý¥¤¥ó¥¿¤Î´ÖÀÜ»²¾È¤Î¿¼¤µ¤òÄê¤á¤Æ¤¤¤Þ
+¤¹¡£
+
+#Another difference is the addressing of indirect blocks. In LogFS,
+#the first 16 pointers in the first indirect block are left empty,
+#corresponding to the 16 direct pointers in the inode. In ext2 (maybe
+#others as well) the first pointer in the first indirect block
+#corresponds to logical block 12, skipping the 12 direct pointers.
+#So where ext2 is using arithmetic to better utilize space, LogFS keeps
+#arithmetic simple and uses compression to save space.
+¤â¤¦°ì¤Ä¤Î°ã¤¤¤Ï¡¢´ÖÀÜ¥Ö¥í¥Ã¥¯¤Î¥¢¥É¥ì¥¹ÊýË¡¤Ë¤¢¤ê¤Þ¤¹¡£LogFS ¤Ç¤Ï¡¢ºÇ½é
+¤Î´ÖÀÜ¥Ö¥í¥Ã¥¯¤Î½é¤á¤«¤é 16 ¸Ä¤Î¥Ý¥¤¥ó¥¿¤Ï¶õ¤Ç»Ä¤µ¤ì¡¢¤³¤ì¤Ï inode ¤Î 16
+¸Ä¤ÎľÀÜ¥Ö¥í¥Ã¥¯¤Î¥Ý¥¤¥ó¥¿¤ËÂбþ¤·¤Þ¤¹¡£ext2 (¶²¤é¤¯Â¾¤Ë¤â) ¤Ç¤Ï¡¢ºÇ½é¤Î
+´ÖÀÜ¥Ö¥í¥Ã¥¯¤Î½é¤á¤«¤é 12 ¸Ä¤Î¥Ý¥¤¥ó¥¿¤Ï¶õ¤Ç»Ä¤µ¤ì¡¢12 ¸Ä¤ÎľÀÜ¥Ö¥í¥Ã¥¯¤Î
+¥Ý¥¤¥ó¥¿¤ò¥¹¥¥Ã¥×¤·¤Æ¤¤¤Þ¤¹¡£¤Ä¤Þ¤ê¡¢ext2 ¤Ç¤Ï·×»»¤ò¹Ô¤Ã¤Æ¥¹¥Ú¡¼¥¹¤ÎÍøÍÑ
+¸úΨ¤ò¤¢¤²¤Æ¤¤¤ë¤Î¤ËÂФ·¤Æ¡¢LogFS ¤Ç¤Ï·×»»¤òñ½ã¤Ëα¤á¤Æ¥¹¥Ú¡¼¥¹¤ÎÀáÌó¤Ï
+°µ½Ì¤Ç¹Ô¤¦¤È¤¤¤¦À߷פǤ¹¡£
+
+#Compression
+#-----------
+°µ½Ì
+----
+
+#Both file data and metadata can be compressed. Compression for file
+#data can be enabled with chattr +c and disabled with chattr -c. Doing
+#so has no effect on existing data, but new data will be stored
+#accordingly. New inodes will inherit the compression flag of the
+#parent directory.
+¥Õ¥¡¥¤¥ë¥Ç¡¼¥¿¤È¥á¥¿¥Ç¡¼¥¿¤ÎξÊý¤¬°µ½Ì²Äǽ¤Ç¤¹¡£¥Õ¥¡¥¤¥ë¥Ç¡¼¥¿¤Î°µ½Ì¤Ï¡¢
+chattr +c ¤Ç͸ú²½¡¢chattr -c ¤Ç̵¸ú²½¤Ç¤¤Þ¤¹¡£¤³¤ÎÀßÄê¤Ï¡¢´û¸¥Ç¡¼¥¿¤Ë
+¤Ï±Æ¶Á¤¬¤Ê¤¯¡¢¿·µ¬¥Ç¡¼¥¿¤ÏÀßÄê¤Ë½¾¤Ã¤Æ½ñ¤¹þ¤Þ¤ì¤Þ¤¹¡£¿·¤·¤¤ inode ¤Ï¡¢¿Æ
+¥Ç¥£¥ì¥¯¥È¥ê¤Î°µ½Ì¥Õ¥é¥°ÀßÄê¤ò°ú¤·Ñ¤®¤Þ¤¹¡£
+
+#Metadata is always compressed. However, the space accounting ignores
+#this and charges for the uncompressed size. Failing to do so could
+#result in GC failures when, after moving some data, indirect blocks
+#compress worse than previously. Even on a 100% full medium, GC may
+#not consume any extra space, so the compression gains are lost space
+#to the user.
+¥á¥¿¥Ç¡¼¥¿¤Ï¾ï¤Ë°µ½Ì¤µ¤ì¤Þ¤¹¡£Ã¢¤·¡¢ÍÆÎÌ·×»»¤Ç¤Ï¤³¤Î°µ½Ì¤Ï̵»ë¤µ¤ì¡¢Èó°µ
+½Ì¤Î¥µ¥¤¥º¤Ç·×»»¤¬¹Ô¤ï¤ì¤Þ¤¹¡£¤½¤Î¤è¤¦¤Ë¤·¤Ê¤¤¾ì¹ç¤Ï¡¢¥Ç¡¼¥¿¤ò°ÜÆ°¤·¤¿ºÝ
+¤Ë´ÖÀÜ¥Ö¥í¥Ã¥¯¤¬¸µ¤Î¥Ç¡¼¥¿¤ËÈæ¤Ù¤Æ°µ½Ì¤µ¤ì¤Ê¤«¤Ã¤¿¾ì¹ç¡¢GC ¤¬¼ºÇÔ¤¹¤ë¤¿¤á
+¤Ç¤¹¡£100% °ìÇդΥá¥Ç¥£¥¢¤Ç¤â¡¢GC ¤ÇÄɲÃÍÆÎ̤ò¾ÃÈñ¤¹¤ë¤³¤È¤Ïµö¤µ¤ì¤Ê¤¤¤¿
+¤á¡¢°µ½Ì¤Ë¤è¤ë¸ú²Ì¤Ï¥æ¡¼¥¶¤«¤é¤ÏÍøÍѤǤ¤Ê¤¤Îΰè¤È¤¤¤¦°·¤¤¤Ë¤Ê¤ê¤Þ¤¹¡£
+
+#However, they are not lost space to the filesystem internals. By
+#cheating the user for those bytes, the filesystem gained some slack
+#space and GC will run less often and faster.
+⤷¡¢¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥àÆâÉôŪ¤Ë¤Ï¤³¤ì¤Ï̵¸úÎΰè¤È¤¤¤¦Ìõ¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£¥æ
+¡¼¥¶¤Ë¤Ï±³¤Î¥µ¥¤¥º¤òÊó¹ð¤¹¤ë¤³¤È¤Ë¤è¤Ã¤Æ¡¢¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤Ï;ʬ¤ÎÎΰè¤ò
+²Ô¤®¡¢GC ¼Â¹Ô²ó¿ô¤¬¸º¤ê¤Þ¤¹¤·¡¢¹â®¤ËÆ°ºî¤¹¤ë¤è¤¦¤Ë¤â¤Ê¤ê¤Þ¤¹¡£
+
+#Garbage Collection and Wear Leveling
+#------------------------------------
+¥¬¥Ù¡¼¥¸¥³¥ì¥¯¥·¥ç¥ó¤È¥¦¥§¥¢¥ì¥Ù¥ê¥ó¥°
+--------------------------------------
+
+#Garbage collection is invoked whenever the number of free segments
+#falls below a threshold. The best (known) candidate is picked based
+#on the least amount of valid data contained in the segment. All
+#remaining valid data is copied elsewhere, thereby invalidating it.
+¥¬¥Ù¡¼¥¸¥³¥ì¥¯¥·¥ç¥ó¤Ï¡¢¶õ¤¥»¥°¥á¥ó¥È¿ô¤¬¤·¤¤¤Ãͤò²¼²ó¤Ã¤¿¾ì¹ç¤Ë¤Ï¤¤¤Ä
+¤âµ¯Æ°¤µ¤ì¤Þ¤¹¡£ºÇÎɤΠ(´ûÃΤÎ) ¸õÊ䤬¡¢¥»¥°¥á¥ó¥È¤Ë³ÊǼ¤µ¤ì¤Æ¤¤¤ë͸ú¥Ç
+¡¼¥¿Î̤¬¾¯¤Ê¤¤½ç¤ËÁªÂò¤µ¤ì¤Þ¤¹¡£»Ä¤Ã¤Æ¤¤¤ë͸ú¥Ç¡¼¥¿¤Ï¾¤Î¾ì½ê¤Ë¥³¥Ô¡¼¤µ
+¤ì¡¢¥»¥°¥á¥ó¥È¤Ï̵¸ú²½¤µ¤ì¤Þ¤¹¡£
+
+#The GC code also checks for aliases and writes then back if their
+#number gets too large.
+GC ¥³¡¼¥É¤Ç¤Ï¥¨¥¤¥ê¥¢¥¹¿ô¤â¥Á¥§¥Ã¥¯¤·¡¢(¤·¤¤¤Ãͤò±Û¤¨¤ë¤Û¤É) Â礤¯¤Ê¤Ã
+¤Æ¤¤¤¿¾ì¹ç¤Ë¤Ï½ñ¤¹þ¤ß¤ò¼Â»Ü¤·¤Þ¤¹¡£
+
+#Wear leveling is done by occasionally picking a suboptimal segment for
+#garbage collection. If a stale segments erase count is significantly
+#lower than the active segments' erase counts, it will be picked. Wear
+#leveling is rate limited, so it will never monopolize the device for
+#more than one segment worth at a time.
+¥¦¥§¥¢¥ì¥Ù¥ê¥ó¥°¤Ï¡¢¥¬¥Ù¡¼¥¸¥³¥ì¥¯¥·¥ç¥óÃæ¤ËºÇŬ¤Ç¤Ï¤Ê¤¤¥»¥°¥á¥ó¥È¤ò¡Ö»þ
+¡¹¡×Ãê½Ð¤¹¤ë¤³¤È¤Ç¼Â¹Ô¤µ¤ì¤Þ¤¹¡£Ìµ¸ú¤Ê¥»¥°¥á¥ó¥È¤Î¾Ãµî¿ô (ÌõÃí:¥Ú¡¼¥¸¤ÎÎß
+ÀѾõî²ó¿ô) ¤¬Í¸ú¤Ê¥»¥°¥á¥ó¥È¤Î¾Ãµî²ó¿ô¤è¤ê¡ÖÌÀÇò¤Ë¾¯¤Ê¤¤¡×¾ì¹ç¡¢¤½¤Î¥»
+¥°¥á¥ó¥È¤¬ÁªÂò¤µ¤ì¤Þ¤¹¡£¥¦¥§¥¢¥ì¥Ù¥ê¥ó¥°¤ÎÉÑÅÙ¤ÏÀ©¸Â¤µ¤ì¤Æ¤ª¤ê¡¢°ìÅ٤˰ì
+¤Ä¤Î¥»¥°¥á¥ó¥Èʬ°Ê¾å¤Ë¥Ç¥Ð¥¤¥¹¤òÀêͤ¹¤ë¤³¤È¤Ï¤¢¤ê¤Þ¤»¤ó¡£
+
+#Values for "occasionally", "significantly lower" are compile time
+#constants.
+¤³¤³¤Ç¡Ö»þ¡¹¡×¤È¡ÖÌÀÇò¤Ë¾¯¤Ê¤¤¡×¤³¤È¤òȽÃǤ¹¤ë³Æ¤·¤¤¤Ãͤϡ¢¥³¥ó¥Ñ¥¤¥ë»þ
+¤ËÀßÄꤵ¤ì¤Þ¤¹¡£
+
+#Hashed directories
+#------------------
+¥Ç¥£¥ì¥¯¥È¥ê¥Ï¥Ã¥·¥å
+--------------------
+
+#To satisfy efficient lookup(), directory entries are hashed and
+#located based on the hash. In order to both support large directories
+#and not be overly inefficient for small directories, several hash
+#tables of increasing size are used. For each table, the hash value
+#modulo the table size gives the table index.
+¸úΨŪ¤Ê lookup() ¤ò¼Â¸½¤¹¤ë¤¿¤á¤Ë¡¢¥Ç¥£¥ì¥¯¥È¥ê¥¨¥ó¥È¥ê¤Ï¥Ï¥Ã¥·¥å²½¤µ¤ì
+¤Æ¥Ï¥Ã¥·¥å¤ò¸µ¤Ë°ÌÃÖ¤¬·èÄꤵ¤ì¤ë¤è¤¦¤Ë¤Ê¤Ã¤Æ¤¤¤Þ¤¹¡£µðÂç¤Ê (¥Õ¥¡¥¤¥ë¿ô¤Î
+¿¤¤) ¥Ç¥£¥ì¥¯¥È¥ê¤ò¥µ¥Ý¡¼¥È¤·¡¢Æ±»þ¤Ë¾®¤µ¤Ê¥Ç¥£¥ì¥¯¥È¥ê¤Ç²áÅÙ¤ËÈó¸úΨ¤Ë
+¤Ê¤é¤Ê¤¤¤è¤¦¤Ë¤¹¤ë¤¿¤á¡¢¥µ¥¤¥º¤¬ (½ç¤Ë) Â礤¯¤Ê¤ëÊ£¿ô¤Î¥Ï¥Ã¥·¥å¥Æ¡¼¥Ö¥ë
+¤¬»È¤ï¤ì¤Æ¤¤¤Þ¤¹¡£³Æ¥Æ¡¼¥Ö¥ë¤Ç¤Ï¡¢¥Ï¥Ã¥·¥åÃͤò¥Æ¡¼¥Ö¥ë¥µ¥¤¥º¤Ç³ä¤Ã¤¿¾ê;
+¤¬¥Æ¡¼¥Ö¥ë¥¤¥ó¥Ç¥Ã¥¯¥¹¤È¤·¤Æ»È¤ï¤ì¤Þ¤¹¡£
+
+#Tables sizes are chosen to limit the number of indirect blocks with a
+#fully populated table to 0, 1, 2 or 3 respectively. So the first
+#table contains 16 entries, the second 512-16, etc.
+¥Æ¡¼¥Ö¥ë¥µ¥¤¥º¤Ï¡¢½ç¤Ë 0¡¢1¡¢2¡¢3 ³¬ÁؤΥơ¼¥Ö¥ë¤Ë´ÖÀÜ¥Ö¥í¥Ã¥¯¤ò°ìÇդ˳Ê
+Ǽ¤·¤¿¿ô¤ÎÀ©¸Â¤ò¸µ¤ËÁªÂò¤µ¤ì¤Þ¤¹¡£¤Ä¤Þ¤êºÇ½é¤Î¥Æ¡¼¥Ö¥ë¤¬ 16 ¥¨¥ó¥È¥ê¤ò³Ê
+Ǽ¤·¡¢ÆóÈÖÌܤ¬ 512-16 ¥¨¥ó¥È¥ê¤ò³ÊǼ¤·¡¢¤Î¤è¤¦¤Ë¤Ê¤ê¤Þ¤¹¡£
+
+#The last table is special in several ways. First its size depends on
+#the effective 32bit limit on telldir/seekdir cookies. Since logfs
+#uses the upper half of the address space for indirect blocks, the size
+#is limited to 2^31. Secondly the table contains hash buckets with 16
+#entries each.
+ºÇ¸å¤Î¥Æ¡¼¥Ö¥ë¤ÏÍÍ¡¹¤Î°ÕÌ£¤ÇÆÃÊ̤Ǥ¹¡£¤Þ¤º¡¢¤½¤Î¥µ¥¤¥º¤Ï¼Â¼ÁŪ¤Ë
+telldir/seekdir ¥¯¥Ã¥¡¼¤Î 32bit À©¸Â¤Ë°Í¸¤·¤Æ¤¤¤Þ¤¹¡£¤³¤ì¤Ï¡¢logfs ¤¬¥¢
+¥É¥ì¥¹¶õ´Ö¤Î¾åȾʬ¤ò´ÖÀÜ¥Ö¥í¥Ã¥¯¤ËÍѤ¤¤Æ¤¤¤ë¤¿¤á¡¢¥µ¥¤¥º¤¬ 2^31 ¤ËÀ©¸Â¤µ
+¤ì¤ë¤¿¤á¤Ç¤¹¡£¼¡¤Ë¡¢¥Æ¡¼¥Ö¥ë¤Ë¤Ï³Æ 16 ¥¨¥ó¥È¥ê¤Î¥Ï¥Ã¥·¥å¥Ð¥±¥Ã¥È¤¬³ÊǼ¤µ
+¤ì¤Æ¤¤¤Þ¤¹¡£
+
+#Using single-entry buckets would result in birthday "attacks". At
+#just 2^16 used entries, hash collisions would be likely (P >= 0.5).
+#My math skills are insufficient to do the combinatorics for the 17x
+#collisions necessary to overflow a bucket, but testing showed that in
+#10,000 runs the lowest directory fill before a bucket overflow was
+#188,057,130 entries with an average of 315,149,915 entries. So for
+#directory sizes of up to a million, bucket overflows should be
+#virtually impossible under normal circumstances.
+¥¨¥ó¥È¥ê¤¬°ì¤Ä¤·¤«¤Ê¤¤¥Ð¥±¥Ã¥È¤Ç¤Ï¡¢¡ÖÃÂÀ¸Æü¹¶·â¡×¤Î±Â¿©¤Ë¤Ê¤Ã¤Æ¤·¤Þ¤¤¤Þ
+¤¹¡£¤¿¤Ã¤¿ 2^16 ¥¨¥ó¥È¥ê¤·¤«»È¤Ã¤Æ¤¤¤Ê¤¤¾ì¹ç¤Ë¤Ï¡¢¥Ï¥Ã¥·¥å¾×ÆͳÎΨ¤Ï
+>=0.5 ¤Ë¤Ê¤ë¤Ç¤·¤ç¤¦¡£¿ô³Ø¤ÏÆÀ°Õ¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¤Î¤Ç¡¢¥Ð¥±¥Ã¥È¤ò°î¤ì¤µ¤ì¤ë
+¤Î¤ËɬÍ×¤Ê 17 ²ó¤Î¾×ÆͤÎÁȤ߹ç¤ï¤»¤Î·×»»¤Ï¤Ç¤¤Þ¤»¤ó¤¬¡¢ºÇ²¼°Ì¤Î¥Ç¥£¥ì¥¯
+¥È¥ê¤ò 10,000 ²óËä¤á¤ë¼Â¸³¤Î·ë²Ì¤Ë¤è¤ë¤È¥Ð¥±¥Ã¥È¤¬°î¤ì¤ë¤Þ¤ÇºÇ¾®¤Ç
+188,057,130 ¥¨¥ó¥È¥ê¤¬ºîÀ®¤Ç¤¡¢Ê¿¶ÑŪ¤Ë¤Ï 315,149,915 ¥¨¥ó¥È¥ê¤¬ºîÀ®²Äǽ
+¤Ç¤·¤¿¡£½¾¤Ã¤Æ¡¢¥Ç¥£¥ì¥¯¥È¥ê¥µ¥¤¥º¤¬ 1,000,000 °Ê²¼¤Ê¤é¡¢¥Ð¥±¥Ã¥È¥ª¡¼¥Ð¥Õ
+¥í¡¼¤ÏÄ̾ï¤Î¾ò·ï²¼¤Ç¤Ï¤Þ¤ºµ¯¤³¤é¤Ê¤¤¤È»×¤¤¤Þ¤¹¡£
+
+#With carefully chosen filenames, it is obviously possible to cause an
+#overflow with just 21 entries (4 higher tables + 16 entries + 1). So
+#there may be a security concern if a malicious user has write access
+#to a directory.
+¥Õ¥¡¥¤¥ë̾¤òÃí°Õ¿¼¤¯ÁªÂò¤¹¤ë¤Ê¤é¡¢Ã±¤Ë 21 ¥¨¥ó¥È¥ê (4 ¤Ä¤Î¾å°Ì¥Æ¡¼¥Ö¥ë +
+16 ¥¨¥ó¥È¥ê + 1) ¤Ç¥ª¡¼¥Ð¥Õ¥í¡¼¤òȯÀ¸¤µ¤»¤ë¤³¤È¤¬¤Ç¤¤ë¤Î¤â¤¢¤¤é¤«¤Ç¤¹¤«
+¤é¡¢°°Õ¤ò»ý¤Ã¤¿¥æ¡¼¥¶¤¬¥Ç¥£¥ì¥¯¥È¥ê¤Ø¤Î½ñ¤¹þ¤ß¸¢¸Â¤ò»ý¤Ã¤Æ¤¤¤ë¾ì¹ç¡¢¥»
+¥¥å¥ê¥Æ¥£¤Î·üÇ°¤¬¤¢¤ë¤Ç¤·¤ç¤¦¡£
+
+#Open For Discussion
+#===================
+º£¸åµÄÏÀ¤¹¤Ù¤ÆâÍÆ
+==================
+
+#Device Address Space
+#--------------------
+¥Ç¥Ð¥¤¥¹¥¢¥É¥ì¥¹¶õ´Ö
+--------------------
+
+#A device address space is used for caching. Both block devices and
+#MTD provide functions to either read a single page or write a segment.
+#Partial segments may be written for data integrity, but where possible
+#complete segments are written for performance on simple block device
+#flash media.
+¥Ç¥Ð¥¤¥¹¥¢¥É¥ì¥¹¶õ´Ö¤Ï¥¥ã¥Ã¥·¥å¤Î¤¿¤á¤ËÍѤ¤¤Þ¤¹¡£¥Ö¥í¥Ã¥¯¥Ç¥Ð¥¤¥¹¤È MTD
+¤ÎξÊý¤¬°ì¥Ú¡¼¥¸Æɤ߽Ф·¤È¥»¥°¥á¥ó¥È½ñ¤¹þ¤ß¤ÎξÊý¤Î´Ø¿ô¤òÄ󶡤·¤Æ¤¤¤Þ¤¹¡£
+¥»¥°¥á¥ó¥È¤Î°ìÉô¤Î¤ß¤ò¥Ç¡¼¥¿À°¹çÀ¤Î¤¿¤á¤Ë½ñ¤¹þ¤à¤³¤È¤â¤¢¤ê¤Þ¤¹¤¬¡¢Ã±½ã
+¤Ê¥Ö¥í¥Ã¥¯¥Ç¥Ð¥¤¥¹·¿¥Õ¥é¥Ã¥·¥å¥á¥Ç¥£¥¢¤Ç¤ÎÀǽ¤Î¤¿¤á¡¢²Äǽ¤Ê¸Â¤ê¥»¥°¥á¥ó
+¥È¤Þ¤ë¤´¤È¤Î½ñ¤¹þ¤ß¤¬¹Ô¤ï¤ì¤Þ¤¹¡£
+
+#Meta Inodes
+#-----------
+¥á¥¿ inode
+----------
+
+#Inodes are stored in the inode file, which is just a regular file for
+#most purposes. At umount time, however, the inode file needs to
+#remain open until all dirty inodes are written. So
+#generic_shutdown_super() may not close this inode, but shouldn't
+#complain about remaining inodes due to the inode file either. Same
+#goes for mapping inode of the device address space.
+inode ¤Ï inode ¥Õ¥¡¥¤¥ë¤Ë½ñ¤¹þ¤Þ¤ì¤Þ¤¹¡£ËؤɤÎÌÜŪ¤Ç¤Ï¡¢inode ¥Õ¥¡¥¤¥ë¤Ï
+ñ¤Ê¤ëÉáÄ̤Υե¡¥¤¥ë¤Ç¤¹¤¬¡¢umount »þ¤À¤±¤Ï inode ¥Õ¥¡¥¤¥ë¤ÏÁ´¤Æ¤Î¥À¡¼¥Æ¥£
+inode ¤Î½ñ¤¹þ¤ß¤¬´°Î»¤¹¤ë¤Þ¤Ç¥ª¡¼¥×¥ó¤·¤Æ¤ª¤¯É¬Íפ¬¤¢¤ê¤Þ¤¹¡£½¾¤Ã¤Æ¡¢
+generic_shutdown_super() ¤Ç¤Ï¤³¤Î inode ¤ò¥¯¥í¡¼¥º¤Ç¤¤Þ¤»¤ó¤¬¡¢¤³¤Î
+inode ¥Õ¥¡¥¤¥ë¤Î¤¿¤á¤Ë¡Ö»Ä¤Ã¤Æ¤¤¤ë inode ¤¬¤¢¤ë¡×¤È¤¤¤¦·Ù¹ð¤ò½Ð¤¹¤³¤È¤âµö
+¤µ¤ì¤Þ¤»¤ó¡£¥Ç¥Ð¥¤¥¹¥¢¥É¥ì¥¹¶õ´Ö¤Ç¤Î¥Þ¥Ã¥×¤µ¤ì¤¿ inode ¤Ë¤Ä¤¤¤Æ¤âƱ¤¸ÌäÂê
+¤¬¤¢¤ê¤Þ¤¹¡£
+
+#Currently logfs uses a hack that essentially copies part of fs/inode.c
+#code over. A general solution would be preferred.
+¸½ºß¡¢logfs ¤Ç¤Ï fs/inode.c ¥³¡¼¥É¤Î°ìÉô¤ò¥³¥Ô¡¼¤·¤¿¥Ï¥Ã¥¯¤ÇÂбþ¤·¤Æ¤¤¤Þ
+¤¹¡£ÈÆÍѤβò·èÊýË¡¤¬µá¤á¤é¤ì¤Æ¤¤¤Þ¤¹¡£
+
+#Indirect block mapping
+#----------------------
+´ÖÀÜ¥Ö¥í¥Ã¥¯¥Þ¥Ã¥Ô¥ó¥°
+----------------------
+
+#With compression, the block device (or mapping inode) cannot be used
+#to cache indirect blocks. Some other place is required. Currently
+#logfs uses the top half of each inode's address space. The low 8TB
+#(on 32bit) are filled with file data, the high 8TB are used for
+#indirect blocks.
+°µ½Ì¤òÍѤ¤¤ë¾ì¹ç¡¢¥Ö¥í¥Ã¥¯¥Ç¥Ð¥¤¥¹ (¤ª¤è¤Ó¥Þ¥Ã¥Ô¥ó¥° inode) ¤Ï´ÖÀÜ¥Ö¥í¥Ã
+¥¯¤ò¥¥ã¥Ã¥·¥å¤¹¤ë¤¿¤á¤ËÍøÍѤ¹¤ë¤³¤È¤Ï¤Ç¤¤Þ¤»¤ó¡£¤É¤³¤«Â¾¤Î¾ì½ê¤¬É¬ÍפÇ
+¤¹¡£¸½ºß¡¢logfs ¤Ï³Æ inode ¥¢¥É¥ì¥¹¶õ´Ö¤Î¾åȾʬ¤ò»È¤¦¤è¤¦¤Ë¤Ê¤Ã¤Æ¤¤¤Þ¤¹¡£
+(32bit ¤Î¾ì¹ç) ²¼°Ì¤Î 8TB ¤Ë¤Ï¥Õ¥¡¥¤¥ë¥Ç¡¼¥¿¤¬³ÊǼ¤µ¤ì¡¢¾å°Ì 8TB ¤Ï´ÖÀÜ¥Ö
+¥í¥Ã¥¯¤Î¤¿¤á¤Ë»È¤ï¤ì¤Þ¤¹¡£
+
+#One problem is that 16TB files created on 64bit systems actually have
+#data in the top 8TB. But files >16TB would cause problems anyway, so
+#only the limit has changed.
+°ì¤ÄÌäÂ꤬¤¢¤Ã¤Æ¡¢64bit ¥·¥¹¥Æ¥à¤ÇºîÀ®¤µ¤ì¤¿ 16TB ¤Î¥Õ¥¡¥¤¥ë¤Ë¤Ï¡¢¼ÂºÝ¤Ë
+¾å°Ì¤Î 8TB ¤Ë¥Ç¡¼¥¿¤¬³ÊǼ¤µ¤ì¤ë¤³¤È¤Ë¤Ê¤ê¤Þ¤¹¡£¤¿¤À¤·¡¢¤¤¤º¤ì¤Ë¤»¤è 16TB
+¤è¤êÂ礤¤¥Õ¥¡¥¤¥ë¤Ç¤ÏÌäÂ꤬ȯÀ¸¤·¤Þ¤¹¤«¤é¡¢À©¸Â¤¬ÊѤï¤Ã¤¿¤À¤±¤È¤¤¤¦¤³¤È
+¤Ç¤¹¡£
+
OSDN Git Service
