Add File System #7
Conversation
|
|
||
| - **File**: Represents a standard file that contains data. | ||
| - **CharDev**: Denotes a character device such as `/dev/null` or `/dev/zero`, including random number generators. | ||
| - **Socket**: Represents a Unix domain socket, used for inter-process communication. |
There was a problem hiding this comment.
This is for all sockets not just unix
|
|
||
| - **Common Metadata (all Inode types)**: | ||
| - `size`: Size of the file in bytes. | ||
| - `uid`, `gid`: User and group identity numbers. |
There was a problem hiding this comment.
It would be more useful to explain how we handle things like uid / gid. Do they have a meaning in our current implementation? Do they get set with setuid, etc.? Are the mode bits checked?
So, instead of just documenting the fields, it may be better to explain how what we have done differs from POSIX so a developer knows what to expect. (This is a general comment, not meant to only apply to uid, gid, etc.)
| - `log_metadata`: Adds a log entry (inode number and potentially some inode data) to a log file, enabling crash recovery or the ability to undo certain changes. | ||
| - `persist_metadata`: Serializes the entire FilesystemMetadata object and writes its data onto disk, allowing the system to remember the state of the filesystem. | ||
|
|
||
| # Path Traversal |
There was a problem hiding this comment.
I think a bit more explanation of how these functions work under the hood would be extremely helpful.
|
|
||
| ## Write Ahead Logging | ||
|
|
||
| - **Log File**: Modifications to filesystem metadata are initially recorded in the "lind.md.log" file before being committed to actual metadata structures. |
There was a problem hiding this comment.
I think a little bit more here would also be useful. Espeically explaining when we log
This doc gives you all the info about filesystem.rs, from its Inode structure to its metadata management, write-ahead logging, and path traversal tools.