added more to writeup again
This commit is contained in:
parent
5f7987ba20
commit
f7c4c13f2a
75
writeup/1.md
75
writeup/1.md
@ -139,3 +139,78 @@ The default user and group ID that processes need to have to access reserved blo
|
||||
u_int16_t e2fs_reserved_ngdb; /* # of reserved gd blocks for resize */
|
||||
```
|
||||
These look like what are meant to be the other part of the superblock if the revision number is 3 or higher. Probably added after ext2 support was initially added. The feature set are flags to be defined later. The UUID, name, where it's mounted, algorithm or whatever are informational flags to remain consistent, and this likely means ext2 didn't have these features. `e2fs_prealloc` must be for each file. `gd` likely stands for group descriptor. With that in mind, let's keep moving down the superblock.
|
||||
|
||||
```c
|
||||
/* Ext3 JBD2 journaling. */
|
||||
u_int8_t e2fs_journal_uuid[16];
|
||||
u_int32_t e2fs_journal_ino;
|
||||
u_int32_t e2fs_journal_dev;
|
||||
u_int32_t e2fs_last_orphan; /* start of list of inodes to delete */
|
||||
u_int32_t e2fs_hash_seed[4]; /* htree hash seed */
|
||||
```
|
||||
|
||||
So it turns out a journal has an identifier, an inode number, also a unique device id? a list of inodes which for some reason is `u_int32_t` and a hash seed which is an array 💀
|
||||
|
||||
`e2fs_last_orphan` is the block number of the list of inodes to delete. The hash seed is an array of 4 `u_int32_t`, which is defined to have a primary and secondary hashing function for improved collision resistance.
|
||||
|
||||
```c
|
||||
u_int8_t e2fs_def_hash_version;
|
||||
u_int8_t e2fs_journal_backup_type;
|
||||
u_int16_t e2fs_gdesc_size;
|
||||
u_int32_t e2fs_default_mount_opts;
|
||||
u_int32_t e2fs_first_meta_bg;
|
||||
u_int32_t e2fs_mkfs_time;
|
||||
```
|
||||
|
||||
As stated before, information is scare 😅 For now, we will do our best by trying to pick apart what we see and fully understand what's going on later in the code hopefully, or once we get in touch with other developers.
|
||||
|
||||
The first value seems to be the default hash version, so some set of flags that indicate what hash function's versions are used. Maybe if the `e2fs_hash_seed` is sha, this would specify between 256, 512, and so forth.
|
||||
|
||||
The second value is the type of backup journaling. It must again be a set of flags determining what items are recorded to be replayed.
|
||||
|
||||
The group descriptor must be information specific to each group, so its size must imply that it's held in a fixed position on disk and has a size dependent on the amount of metadata we want to hold.
|
||||
|
||||
The `e2fs_first_meta_bg` appears to be the first metadata block group in case the simplifications were cryptic. It contains other important information not specified in the superblock already.
|
||||
|
||||
The last value holds when the filesystem was created--when mkfs was last run-- which is useful metadata information but doesn't appear to be directly useful, unless we are checking data integrity.
|
||||
|
||||
```c
|
||||
u_int32_t e2fs_journal_backup[17];
|
||||
```
|
||||
|
||||
I could not find any information on this field so far. We want to allocate 17 double words for information the journal backs up? Or is this where the logs are stored (but wouldn't that be too small?) we don't know yet.
|
||||
|
||||
```c
|
||||
u_int32_t e2fs_bcount_hi; /* high bits of blocks count */
|
||||
u_int32_t e2fs_rbcount_hi; /* high bits of reserved blocks count */
|
||||
u_int32_t e2fs_fbcount_hi; /* high bits of free blocks count */
|
||||
u_int16_t e2fs_min_extra_isize; /* all inodes have some bytes */
|
||||
u_int16_t e2fs_want_extra_isize;/* inodes must reserve some bytes */
|
||||
```
|
||||
|
||||
While these have comments, they probably make no sense to the non kernel developer 🤣
|
||||
|
||||
At this point I think it is safe to say this is beyond the journaling part of the superblock, even though there is no padding or comment to indicate otherwise. The high bits mean the more significant bits, so it's easier to access, even though these are `u_int32_t` like the regular counts 🤔 must be more useful in 64-bit mode, I guess.
|
||||
|
||||
The last two fields are quiet confusing, comment wise. However all they mean is that there is a minimum amount of bytes an inode should allocate, and an ideal number.
|
||||
|
||||
```c
|
||||
u_int32_t e2fs_flags; /* miscellaneous flags */
|
||||
u_int16_t e2fs_raid_stride; /* RAID stride */
|
||||
u_int16_t e2fs_mmpintv; /* seconds to wait in MMP checking */
|
||||
u_int64_t e2fs_mmpblk; /* block for multi-mount protection */
|
||||
u_int32_t e2fs_raid_stripe_wid; /* blocks on data disks (N * stride) */
|
||||
```
|
||||
|
||||
These are other helpful utilities. RAID means Redundant Array of Independent Disks. The number of blocks on each disk is the `raid_stride` times the `raid_stripe_width`: in simple words, the amount of duplicate copies of the disk you have.
|
||||
|
||||
MMP is multi-mount protection: a block holds advanced information for that, and there are a few seconds you need to wait. The last item says how many blocks there are on each data disk to be multiplied with `e2fs_raid_stride`.
|
||||
|
||||
```c
|
||||
u_int8_t e2fs_log_gpf; /* FLEX_BG group size */
|
||||
u_int8_t e2fs_chksum_type; /* metadata checksum algorithm used */
|
||||
u_int8_t e2fs_encrypt; /* versioning level for encryption */
|
||||
u_int8_t e2fs_reserved_pad;
|
||||
```
|
||||
|
||||
The values seem to get more and more disorganized as we reach the end of the block
|
||||
|
Loading…
Reference in New Issue
Block a user