Lines Matching full:remap
23 <Literal remap="tt">ext2 filesystem editor project (EXT2ED)</Literal>.
108 The <Literal remap="tt">Second Extended File System (Ext2fs)</Literal> is very popular among Linux
137 A <Literal remap="tt">filesystem</Literal> consists of two word - <Literal remap="tt">file</Literal> and <Literal remap="tt">system</Literal>.
141 Everyone knows the meaning of the word <Literal remap="tt">file</Literal> - A bunch of data put
148 This is where the <Literal remap="tt">system</Literal> comes in - Instead of just throwing the data
149 to the device, we generalize and construct a <Literal remap="tt">system</Literal> which will
157 Normally, by <Literal remap="tt">mounting</Literal> filesystems, we just use the nice and logical
177 <Literal remap="tt">Minix</Literal> filesystem. Today, Linux has the ability to support several
196 into small units called <Literal remap="tt">blocks</Literal>. A block is the smallest unit which
197 can be allocated. Each block in the filesystem can be <Literal remap="tt">allocated</Literal> or
198 <Literal remap="tt">free</Literal>.
202 The Ext2fs source code refers to the concept of <Literal remap="tt">fragments</Literal>, which I
214 Ext2fs groups together a fixed number of sequential blocks into a <Literal remap="tt">group
228 Each file in the filesystem is reserved a special <Literal remap="tt">inode</Literal>. I don't want
230 much like a <Literal remap="tt">block</Literal> - Each blocks group contains a limited number of
231 inode, while any specific inode can be <Literal remap="tt">allocated</Literal> or
232 <Literal remap="tt">unallocated</Literal>.
241 Each blocks group is accompanied by a <Literal remap="tt">group descriptor</Literal>. The group
266 The last three variables: <Literal remap="tt">bg_free_blocks_count, bg_free_inodes_count and bg_used_dirs_count</Literal> provide statistics about the use of the three
267 resources in a blocks group - The <Literal remap="tt">blocks</Literal>, the <Literal remap="tt">inodes</Literal> and the
268 <Literal remap="tt">directories</Literal>. I believe that they are used by the kernel for balancing
273 <Literal remap="tt">bg_block_bitmap</Literal> contains the block number of the <Literal remap="tt">block allocation
279 <Literal remap="tt">bg_inode_bitmap</Literal> is fully analogous to the previous variable - It
280 contains the block number of the <Literal remap="tt">inode allocation bitmap block</Literal>, which
285 <Literal remap="tt">bg_inode_table</Literal> contains the block number of the start of the
286 <Literal remap="tt">inode table of the current blocks group</Literal>. The <Literal remap="tt">inode table</Literal> is
297 <Literal remap="tt">group descriptors table</Literal>.
315 <Literal remap="tt">bit</Literal> in the block bitmap indicated whether a specific block in the
327 filesystem's <Literal remap="tt">superblock</Literal>, which will be explained later.
367 A value of "<Literal remap="tt">1</Literal>" in the appropriate bit signals that the block is
368 allocated, while a value of "<Literal remap="tt">0</Literal>" signals that the block is
374 same value, making the byte's value <Literal remap="tt">0</Literal> or <Literal remap="tt">0ffh</Literal>. This is done by
388 the work <Literal remap="tt">block</Literal> replaced by <Literal remap="tt">inode</Literal>. Typically, there are much less
391 which is listed in the <Literal remap="tt">superblock</Literal>.
434 Each inode takes up 128 bytes in the filesystem. By default, <Literal remap="tt">mke2fs</Literal>
447 <Literal remap="tt">s_inodes_per_group</Literal>. For example, if there are 2000 inodes per group,
539 called <Literal remap="tt">direct blocks</Literal>. The advantage is that once the kernel has the
542 <Literal remap="tt">i_block[0] to i_block[11]</Literal>.
546 <Literal remap="tt">i_block[12]</Literal> is the <Literal remap="tt">indirect block</Literal> - The block pointed by
547 i_block[12] will <Literal remap="tt">not</Literal> be a data block. Rather, it will just contain a
551 <Literal remap="tt">indirect block</Literal> method. The penalty in this case, compared to the
553 We need <Literal remap="tt">two</Literal> accesses to reach the required data block.
557 In much the same way, <Literal remap="tt">i_block[13]</Literal> is the <Literal remap="tt">double indirect block</Literal>
558 and <Literal remap="tt">i_block[14]</Literal> is the <Literal remap="tt">triple indirect block</Literal>.
562 <Literal remap="tt">i_block[13]</Literal> points to a block which contains pointers to indirect
577 The i_mode variable is used to determine the <Literal remap="tt">inode type</Literal> and the
578 associated <Literal remap="tt">permissions</Literal>. It is best described by representing it as an
588 The rightmost 4 digits are <Literal remap="tt">bit options</Literal> - Each bit has its own
594 in the known form <Literal remap="tt">rwxrwxrwx</Literal>. Digit 2 refers to the user, digit 1 to
600 A <Literal remap="tt">smarter</Literal> permissions control is one of the enhancements planned for
612 <Literal remap="tt">set VTX</Literal>. I still don't know what is the meaning of "VTX".
616 Bit number 10 signals that the file is <Literal remap="tt">set group id</Literal> - I don't know
621 Bit number 11 signals that the file is <Literal remap="tt">set user id</Literal>, which means that
643 <Literal remap="tt">01</Literal> - The file is a <Literal remap="tt">FIFO</Literal>.
649 <Literal remap="tt">02</Literal> - The file is a <Literal remap="tt">character device</Literal>.
655 <Literal remap="tt">04</Literal> - The file is a <Literal remap="tt">directory</Literal>.
661 <Literal remap="tt">06</Literal> - The file is a <Literal remap="tt">block device</Literal>.
667 <Literal remap="tt">10</Literal> - The file is a <Literal remap="tt">regular file</Literal>.
673 <Literal remap="tt">12</Literal> - The file is a <Literal remap="tt">symbolic link</Literal>.
679 <Literal remap="tt">14</Literal> - The file is a <Literal remap="tt">socket</Literal>.
704 <Literal remap="tt">i_ctime</Literal> - The time in which the inode was last allocated. In
711 <Literal remap="tt">i_mtime</Literal> - The time in which the file was last modified.
717 <Literal remap="tt">i_atime</Literal> - The time in which the file was last accessed.
723 <Literal remap="tt">i_dtime</Literal> - The time in which the inode was deallocated. In
738 <Literal remap="tt">i_size</Literal> contains information about the size of the object presented by
751 <Literal remap="tt">i_uid</Literal> and <Literal remap="tt">i_gid</Literal>.
761 explained that each <Literal remap="tt">directory entry</Literal> points to an inode. It is quite
762 possible that a <Literal remap="tt">single inode</Literal> will be pointed to from <Literal remap="tt">several</Literal>
763 directories. In that case, we say that there exist <Literal remap="tt">hard links</Literal> to the
769 <Literal remap="tt">i_links_count</Literal>. The variable is set to "1" when first allocating the
776 The name <Literal remap="tt">hard link</Literal> is used to distinguish between the alias method
777 described above, to another alias method called <Literal remap="tt">symbolic linking</Literal>,
788 attributes are stored in the variable <Literal remap="tt">i_flags</Literal>. <Literal remap="tt">i_flags</Literal> is a 32
791 <Literal remap="tt">undelete</Literal> and the <Literal remap="tt">compress</Literal> features are not implemented, and
815 <Literal remap="tt">undelete</Literal> feature in future Ext2fs developments.
860 <Literal remap="tt">Remy Card</Literal>) to check if the file should not be dumped.
874 The <Literal remap="tt">hard links</Literal> presented above are just another pointers to the same
875 inode. The important aspect is that the inode number is <Literal remap="tt">fixed</Literal> when
910 <Literal remap="tt">Symbolic link</Literal>, on the other hand, is analyzed at <Literal remap="tt">run time</Literal>. A
911 symbolic link is just a <Literal remap="tt">pathname</Literal> which is accessible from an inode.
913 kernel reaches a symbolic link, it will <Literal remap="tt">follow it in run time</Literal> using
918 As such, symbolic link can be made <Literal remap="tt">across different filesystems</Literal> and a
939 inode, on the <Literal remap="tt">i_block[0] - i_block[15]</Literal> variables, since those are not
940 needed in that case. This is called <Literal remap="tt">fast</Literal> symbolic link. It is fast
943 an inode. The length of the pathname is stored in the <Literal remap="tt">i_size</Literal>
954 <Literal remap="tt">i_block[0]</Literal>) and the pathname is stored in it. It is called slow
956 The length is again saved in <Literal remap="tt">i_size</Literal>.
967 <Literal remap="tt">i_version</Literal> is used with regard to Network File System. I don't know
998 Inode 1 is the <Literal remap="tt">bad blocks inode</Literal> - I believe that its data
1006 Inode 2 is the <Literal remap="tt">root inode</Literal> - The inode of the root directory.
1013 Inode 3 is the <Literal remap="tt">acl index inode</Literal>. Access control lists are
1021 Inode 4 is the <Literal remap="tt">acl data inode</Literal>. Of course, the above applies
1028 Inode 5 is the <Literal remap="tt">boot loader inode</Literal>. I don't know its
1035 Inode 6 is the <Literal remap="tt">undelete directory inode</Literal>. It is also a
1042 Inodes 7-10 are <Literal remap="tt">reserved</Literal> and currently not used.
1082 <Literal remap="tt">name</Literal> field above just contains the file name. Note that it is
1083 <Literal remap="tt">not zero terminated</Literal>; Instead, the variable <Literal remap="tt">name_len</Literal> contains
1088 The variable <Literal remap="tt">rec_len</Literal> is provided because the directory entries are
1091 <Literal remap="tt">rec_len</Literal>. If the directory entry is the last in the block, it is
1097 The <Literal remap="tt">inode</Literal> variable points to the inode of the above file.
1111 The <Literal remap="tt">superblock</Literal> is a block which contains information which describes
1116 The superblock is located at the <Literal remap="tt">fixed offset 1024</Literal> in the device. Its
1199 The ext2 filesystem's superblock is identified by the <Literal remap="tt">s_magic</Literal> field.
1213 By using the word <Literal remap="tt">fixed</Literal>, I mean fixed with respect to a particular
1219 The <Literal remap="tt">block size</Literal> is determined by using the <Literal remap="tt">s_log_block_size</Literal>
1225 <Literal remap="tt">s_inodes_count</Literal> contains the total number of available inodes.
1229 <Literal remap="tt">s_blocks_count</Literal> contains the total number of available blocks.
1233 <Literal remap="tt">s_first_data_block</Literal> specifies in which of the <Literal remap="tt">device block</Literal> the
1234 <Literal remap="tt">superblock</Literal> is present. The superblock is always present at the fixed
1236 block size is 1024, the superblock will be at <Literal remap="tt">block 1</Literal> with respect to
1238 <Literal remap="tt">block 0</Literal> of the device, and in that case <Literal remap="tt">s_first_data_block</Literal>
1243 <Literal remap="tt">s_blocks_per_group</Literal> contains the number of blocks which are grouped
1248 <Literal remap="tt">s_inodes_per_group</Literal> contains the number of inodes available in a group
1254 <Literal remap="tt">s_creator_os</Literal> contains a code number which specifies the operating
1261 <Literal remap="tt">Linux</Literal> :-) is specified by the value <Literal remap="tt">0</Literal>.
1267 <Literal remap="tt">Hurd</Literal> is specified by the value <Literal remap="tt">1</Literal>.
1273 <Literal remap="tt">Masix</Literal> is specified by the value <Literal remap="tt">2</Literal>.
1282 <Literal remap="tt">s_rev_level</Literal> contains the major version of the ext2 filesystem.
1283 Currently this is always <Literal remap="tt">0</Literal>, as the most recent version is 0.5B. It
1290 <Literal remap="tt">s_log_frag_size</Literal> and <Literal remap="tt">s_frags_per_group</Literal> are always equal to
1291 <Literal remap="tt">s_log_block_size</Literal> and <Literal remap="tt">s_blocks_per_group</Literal>, respectively.
1313 <Literal remap="tt">e2fsck by Theodore Ts'o</Literal> for <Literal remap="tt">automatic</Literal> analysis and
1314 correction, or perhaps <Literal remap="tt">debugfs by Theodore Ts'o</Literal> and
1315 <Literal remap="tt">EXT2ED by myself</Literal>, for <Literal remap="tt">hand</Literal> analysis and correction.
1324 The <Literal remap="tt">s_state</Literal> variable is used by the kernel to pass the identification
1331 <Literal remap="tt">bit 0</Literal> of s_state is reset when the partition is mounted and
1341 <Literal remap="tt">bit 1</Literal> of s_state is set by the kernel when it detects an
1353 parameter <Literal remap="tt">s_errors</Literal>:
1359 The kernel will ignore the error and continue if <Literal remap="tt">s_errors=1</Literal>.
1366 <Literal remap="tt">s_errors=2</Literal>.
1372 A kernel panic will be issued if <Literal remap="tt">s_errors=3</Literal>.
1390 Of-course, <Literal remap="tt">e2fsck</Literal> will check the filesystem if errors were detected
1395 In addition, each time the filesystem is mounted, <Literal remap="tt">s_mnt_count</Literal> is
1396 incremented. When s_mnt_count reaches <Literal remap="tt">s_max_mnt_count</Literal>, <Literal remap="tt">e2fsck</Literal>
1398 then zero s_mnt_count. <Literal remap="tt">s_max_mnt_count</Literal> is a tunable parameter.
1403 the <Literal remap="tt">s_lastcheck</Literal> variable. The user tunable parameter
1404 <Literal remap="tt">s_checkinterval</Literal> will contain the number of seconds which are allowed
1405 to pass since <Literal remap="tt">s_lastcheck</Literal> until a check is reforced. A value of
1406 <Literal remap="tt">0</Literal> disables time-based check.
1415 <Literal remap="tt">s_r_blocks_count</Literal> contains the number of disk blocks which are
1416 reserved for root, the user whose id number is <Literal remap="tt">s_def_resuid</Literal> and the
1417 group whose id number is <Literal remap="tt">s_deg_resgid</Literal>. The kernel will refuse to
1418 allocate those last <Literal remap="tt">s_r_blocks_count</Literal> if the user is not one of the
1424 <Literal remap="tt">s_def_resuid</Literal> and <Literal remap="tt">s_def_resgid</Literal> contain the id of the user and
1434 <Literal remap="tt">s_free_blocks_count</Literal> contains the current number of free blocks
1439 <Literal remap="tt">s_free_inodes_count</Literal> contains the current number of free inodes in the
1444 <Literal remap="tt">s_mtime</Literal> contains the time at which the system was last mounted.
1448 <Literal remap="tt">s_wtime</Literal> contains the last time at which something was changed in the
1501 <Literal remap="tt">Remy Card</Literal>
1504 code, and some of the ext2 utilities. <Literal remap="tt">Remy Card</Literal> is also the
1506 Specifically, he is the author of <Literal remap="tt">File Management in the Linux
1507 Kernel</Literal> and of <Literal remap="tt">The Second Extended File System - Current
1515 <Literal remap="tt">Wayne Davison</Literal>
1523 <Literal remap="tt">Stephen Tweedie</Literal>
1526 slides <Literal remap="tt">Optimizations in File Systems</Literal>.
1532 <Literal remap="tt">Theodore Ts'o</Literal>
1535 <Literal remap="tt">libext2fs</Literal> (which I didn't use, simply because I didn't know
1545 Lastly, I would like to thank, of-course, <Literal remap="tt">Linus Torvalds</Literal> and the
1546 <Literal remap="tt">Linux community</Literal> for providing all of us with such a great operating
