ext
1. Gral. Info.
-
mke2fs: create a Linux ext2 filesystem
-
chattr: change file attributes on a ext2 filesystem
A don't update atime c compressed j data journalling
S synchronous updates d no dump s secure deletion
a append only i immutable u undeletable
-
"To keep root from re-running the chattr command, you need to have CAP_LINUX_IMMUTABLE unavailable, either by removing it from the capability bounding set, or using a Linux security patch that does the same thing effectivly. (SELinux, Lids, GrSecurity, etc.)" Brian Hatch
-
debugfs: ext2/3 file system debugger
-
fsck.ext2/3 works directly on files dumped with dd
-
If you want to mount a system dump made with dd dump directly with the -o loop option, add bs=1024 while making image using dd (default block size for dd is 512 bytes ???)
-
ext2 -> ext3: tune2fs -j /dev/hda1
ext3 -> ext2: tune2fs -O ^has_journal /dev/hdb1
-
The tune2fs program can add a journal to an existing ext2 file system. If the file system is already mounted while it is being transitioned, the journal will be visible as the file .journal in the root directory of the file system. If the file system is not mounted, the journal will be hidden and will not appear in the file system.
Just run tune2fs -j /dev/hda1 (or whatever device holds the file system you are transitioning) and change ext2 to ext3 on the matching lines in /etc/fstab. If you are transitioning your root file system, you will have to use an initrd to boot. Run the mkinitrd program as described in the manual and make sure that your LILO or GRUB configuration loads the initrd. (If you fail to make that change, the system will still boot, but the root file system will be mounted as ext2 instead of ext3 - you can tell this by looking at the output of the command cat /proc/mounts.) More information on tune2fs can be found in the tune2fs man page (man tune2fs)
-
extX is Group-oriented: groups that already have a lot of data and little activity will not be overwritten as fast as data in groups that have a lot of write activity.
+ File created: MAC updated ; D set to 0
Parent's dir MC updated
+ File copied: Originai parent's dir & file's A updated
New file's MAC updated
New parent's dir MC updated
+ File moved: Original Parent dir MAC updated
Original file dissapears
New Parent dir MC updated
New file same MA as original, updated C
File moved inside same vol: same inode used
File moved to new vol: original inode unallocated -> MACD updated
-
Blocks:
-
The size of a block group is frequently
-
Not every allocated block is allocated to a file (e.g. administrative data like SB, GDT, Block/Inode Bitmaps, Inode tables.
-
Block allocation:
-
When a block is allocated to an inode, Linux will use a first-available strategy and try to allocate a block in the same Group as the inode.
-
SB, GDT, Block/Inode Bitmaps, Inode tables are considered allocated, even when they are not allocated to a file.
-
File slack:
-
When writing a file, Linux zeros out the unused bytes of the last block used by the file -> There should not be file slack.
-
Group Blocks:
-
Linux creates block group sizes so the Block Bitmap needs just 1 block. Filesystems with a 4096 byte block size have 32768 (4096x8) blks per group
10. Format
<-- --- --- --- --- --- --- PARTITION --- --- --- --- --- --- -->
+----------+-------------+-------------+-------------+-------------+
| Boot Blk | Blk Group | Blk Group | Blk Group | Blk Group |
+----------+-------------+-------------+-------------+-------------+
* BB - Boot Block: 2 sectors (1024 bytes)
[<--]<--- --- --- --- --- --- --- Blk Group --- --- --- --- --- --- ->
+----+----+--------------+---------+-----------+------------+-----------+
|[BB]| SB | Grp Desc Tbl | Blk Bmp | Inode Bmp | Inode Tbl | Data Blks |
+----+----+--------------+---------+-----------+------------+-----------+
Size Comments
[BB] 1024 bytes only on Block Group 0
SB 1024 bytes
GDT 24 bytes
Blk Bmp # blocks in group / 8 bytes
Inode Bmp # inodes in group / 8 bytes
Inode Tbl # inodes in group x inode size bytes
Boot Block
-
BB - Boot Block: 2 sectors (1024 bytes)
-
Unused on non-boot file systems (usually 0's)
-
Located in the 1024 bytes before the SB.
-
The boot code will be executed after control is passed to it from the boot code in the MBR in sector 0 of the disk. The boot code will know which blocks have been allocated to the kernel and will load it into mem
-
Many Linux systems do not have boot code in the file system with the kernel: the boot loader in the MBR knows where the kernel is located so it will directly load the kernel (no boot code in the filesystem is needed).
Super-Block
-
Size: 1024 bytes
-
The main (first) SB is located 1024 bytes from the start of the filesystem (if the block size > 1024 this means that the SB is in the first block of with an offset of 1024).
-
Backup (not used) copies of the SB are located in the 1st data block of each block group, unless "sparse SB" is enabled (default), in which case only somme block grps contain backups of the SB & the block grp descriptor
-
The SB contains critical info: block size & group size · 3rd sector inside the Block Descriptors area.
Offset Description
* 1 0 [4] Total Inodes in filesystem
* 2 4 [4] Total blocks in filesystem
3 8 [4] No. of blocks reserved for superuser (prevent fillup)
4 12 [4] No. of unallocated blocks
5 16 [4] No. of unallocated Inodes
* 6 20 [4] Block where block group 0 starts
* 7 24 [4] Block size (no. of places to shift 1024 to the left)
* 8 28 [4] Fragment size (no. of places to shift 1024 to the left)
* 9 32 [4] Blocks per block group
* 10 36 [4] Fragments per block group
* 11 40 [4] Inodes per block group
12 44 [4] Mount time
13 48 [4] Last superblock write time
14 52 [2] Mount count
15 54 [2] Max Mount count
16 56 [2] Magic number (SB indicator): 0xEF 53 (Big Endian)
17 58 [2] State of the file system
18 60 [2] Error handling method
19 62 [2] Minor version
20 64 [4] Last consistency check time
21 68 [4] Check Interval (max between checks)
22 72 [4] Creator OS
23 76 [4] Major Version
24 80 [2] UID that can use reserved blocks
25 82 [2] GID that can use reserved blocks
26 84 [4] First non-reserved inode in file system
* 27 88 [2] Size of each inode structure
28 90 [2] Block group that this superblock is part of (if backup)
29 92 [4] Compatible feature flags
* 30 96 [4] Incompatible feature flags
31 100 [4] Read only feature flags
32 104 [16] File system ID
33 120 [16] Volume Name
34 136 [64] Path where last mounted on
35 200 [4] Algorithm usage bitmap
36 204 [1] No. of blocks to preallocate for files
37 205 [1] No. of blocks to preallocate for dirs
38 206 [2] Unused
39 208 [16] Journal ID
40 224 [4] Journal inode
41 228 [4] Journal device
42 232 [4] Head of orphan inode list
43 236-1023 Unused
To find out the bytes per block:
· 2^(n+1) -> No. sectors per block x 512 = Bytes per block
where n -> Logical block size
· Right bit shift the Logical block size, and x 1024
· Features:
* Compatible::
0x0001 Preallocate dir blocks to reduce fragmentation
0x0002 AFS server inodes exist
0x0004 File system has a journal (Ext3)
0x0008 Inodes have extended attributes
0x0010 File system can resize itself for larger partitions
0x0020 Dirs use hash index
* Incompatible:
0x0001 Compression
0x0002 Dir. entries contain a file type field
0x0004 File system needs recovery
0x0008 File system uses a journal device
* Read only compatible:
0x0001 Sparse Super-Block and GDTs
Enabled by default
Copies typically in: 1, 3, 7, 9, 25, 27
0x0002 File system contains a large file
0x0004 Dirs. use B-Trees (not implemented)
Group Descriptor Table
-
Characteristics:
-
Size: 24 bytes
-
Describes where SB, GDT, Inode Tables, Inode & Block Bitmaps can be found.
-
The Group Descriptor Table (GDT) is located in the block following the SB (starting at the begining of the block, no offset).
-
Backup (not used) copies of the GDT are located in each block group, unless "sparse SB" is enabled (default), in which case only somme block grps contain backups of the SB & the GDT
Offset
0[4] Location of the block bitmap
4[4] Location of the Inode bitmap
8[4] First block of the Inode table
12[2] Free blocks in the group
14[2] Free Inodes in the group
16[2] Inodes allocated to dirs
18[2] padding
20[4] reserved[3]
Block Bitmap
-
Size: # blocks in the group / 8 (1 bit -> 1 block)
-
Used to control the allocation of the blocks within its group.
-
Its starting block addr is given in the GDT.
Inode Bitmap
-
Size: # inodes in the group / 8 (1 bit -> 1 inode)
-
Used to control the allocation of inodes within its group.
-
Its starting block addr is given in the GDT.
-
In gral there are fewer inodes than blocks per group, but this can be
-
changed when the filesystem is created.
Format: Inode Table
-
Characteristics:
-
Its starting block addr is given in the GDT.
-
Size: # inodes per group x inode size (typically 128b, defined in SB)
-
To find a particular inode, just look go to the offset "128xinode #"
-
Size: Typically 128b - Exact size defined in the SB
Offset
0[2] Type of file and access rights
2[2] File owner (UID)
4[4] Logical size in bytes
8[4] Last accessed time
12[4] Last changed time (inode info modified)
16[4] Last modified time (contents modified)
20[4] Deleted time
24[2] File group (GID)
26[2] Links pointing to the file
28[4] No. blocks allocated to the file (sectors)
32[4] Flags
36[4] Reserved1
40-87[4] 12 Direct Block Pointers - 0s if not allocated
88[4] 1 Single indirect block pointer
92[4] 1 Double indirect block pointer
96[4] 1 Triple indirect block pointer
100[4] Generation Number (NFS)
104[4] Extended Attribute Block (File ACL)
108[4] Upper 32 bits of size / Dir. ACL
112[4] Block address of fragment
116[1] Fragment index in block
117[1] Fragment size
118[2] Unused
120[2] Upper 16 bits of user ID
122[2] Upper 16 bist of group ID
124[4] Unused
· Single/Double/Triple:
* If the cluster is 4096 bytes, as inode pointers are 4b -> 1024 pointers
-
Reserved Inodes (1 -> 10):
-
1: Bad Blocks
-
2: Root dir.
-
8: Journal typically (can be redefined in the SB)
-
Offset
20 Partition name
-
If the cluster is 4096 bytes, as inode pointers are 4 bytes -> 1024 pointers
Data Blocks
-
The contents of the file is just the path of the pointed file, nothing else.
-
They are resident when they are less than 60 chars long (60=4*15 -> they occupy the 12 direct + 3 indirect block pointers in the inode).
Offset
0[4] Inode number
4[2] Record Length (rounded to a multiple of 4)
6[1] Name Length (1 byte -> 255 chars long)
7[1] Type of file
0: Unknown 1: Regular File 2: Dir. 3: Char. Dev.
4: Block Dev. 5: FIFO 6: SOCK 7: Symlink
8[var] File name (4-byte padded ???)
-
Length: multiple of the block size (dirs are allocated full blocks).
-
A directory is made up of a collection of records.
-
Dir Entry (8b + name length):
Journal
-
Journal Inode is defined in the SB, but usually is inode 8.
-
Journal Data is all written in Big Endian ordering.
-
Journal data structures:
. Common Header:
0[4] Signature: 0xC03B3998
4[4] Block Type: 1->Descriptor 2-> Commit 3->SBv1
4->SBv2 5-> Revoke
8[4]
. Journal Super-Block:
* Located in the 1st blk of the journal.
* Format:
0[12] Common Hdr
12[4] Journal Block Size
16[4] No. of journal blocks
20[4] Journal Block where journal actually starts
24[4] Sequence Number of 1st transaction
28[4] Journal Block of 1st transaction
32[4] Error Number
v2 extensions:
36[4] compatible Features
40[4] Incompatible features
44[4] Read only compatible features
48[16] Journal UUID
64[4] No. of file systems using journal
68[4] Location of SB copy
72[4] Max journal blks per transaction
76[4] Max file system blks per transaction
80-255 Unused
256-1023 16b IDs of file systems using the journal
. Descriptor
* Format:
0[4] File system block
4[4] Entry flags
0x01 Journal blk has been escaped
0x02 Entry has the same UUID as the previous
0x04 Block was deleted by this transaction (not used)
0x08 Last entry in descriptor blk
8[16] UUID (not present if SAME_UUID flag set)
. Commit
* It has just the common Hdr
. Revoke
* Format:
0[12] Common Hdr
12[4] Size in bytes of revoke data
16-SIZE List of 4-byte file system blk addrs
Filesystem Operations
File Deletion
-
When a file or dir. is deleted, its name needs to be modified so that the OS does not print it. The OS hides a dir. entry by increasing the record length of the previous dir. entry so it points after the one hidden.
-
The file size in the inode table is set to 0
-
Pointers is set zeroed
-
Sectors are set to unallocated (0)
-
Deletion date is populated
-
The dir entry does not change (???)
