blog: Add blog post on new vfs stack - #520
Merged
Merged
Conversation
razvand
approved these changes
Sep 12, 2025
razvand
left a comment
Contributor
There was a problem hiding this comment.
All good, thanks.
Reviewed-by: Razvan Deaconescu razvand@unikraft.io
StefanJum
requested changes
Sep 12, 2025
StefanJum
left a comment
Member
There was a problem hiding this comment.
Looks great @andreittr, some minor linting comments (basically add empty lines after headings and before lists). Other than that everything is ok, I'll approve after the changes.
Comment on lines
+37
to
+39
| #### Insufficient Abstraction | ||
| In vfscore, a file's open state (e.g., `lseek` position) and file descriptor are tightly bound to the file object, appearing as fields in its struct. |
Member
There was a problem hiding this comment.
Suggested change
| #### Insufficient Abstraction | |
| In vfscore, a file's open state (e.g., `lseek` position) and file descriptor are tightly bound to the file object, appearing as fields in its struct. | |
| #### Insufficient Abstraction | |
| In vfscore, a file's open state (e.g., `lseek` position) and file descriptor are tightly bound to the file object, appearing as fields in its struct. |
Comment on lines
+43
to
+46
| #### Files == Paths | ||
| In a similar limitation to the above, vfscore views the filesystem as a _reversible_ mapping of paths to files, implying another 1:1 relationship that does not exist in practice. |
Member
There was a problem hiding this comment.
Suggested change
| #### Files == Paths | |
| In a similar limitation to the above, vfscore views the filesystem as a _reversible_ mapping of paths to files, implying another 1:1 relationship that does not exist in practice. | |
| #### Files == Paths | |
| In a similar limitation to the above, vfscore views the filesystem as a _reversible_ mapping of paths to files, implying another 1:1 relationship that does not exist in practice. |
Comment on lines
+48
to
+52
| #### Absolute Lookups | ||
| Building on its assumptions about the mapping of paths to files, vfscore treats all lookups as absolute, roughly following two steps: (1) look up absolute path prefix in mount table to determine mount root, and (2) delegate lookup relative to mount root to driver. |
Member
There was a problem hiding this comment.
Suggested change
| #### Absolute Lookups | |
| Building on its assumptions about the mapping of paths to files, vfscore treats all lookups as absolute, roughly following two steps: (1) look up absolute path prefix in mount table to determine mount root, and (2) delegate lookup relative to mount root to driver. | |
| #### Absolute Lookups | |
| Building on its assumptions about the mapping of paths to files, vfscore treats all lookups as absolute, roughly following two steps: (1) look up absolute path prefix in mount table to determine mount root, and (2) delegate lookup relative to mount root to driver. |
Comment on lines
+53
to
+58
| #### Monolithic Nature | ||
| Unlike most Unikraft core libraries, and counter to the unikernel philosophy, vfscore is unusually monolithic, bearing responsibility across many abstraction layers. |
Member
There was a problem hiding this comment.
Suggested change
| #### Monolithic Nature | |
| Unlike most Unikraft core libraries, and counter to the unikernel philosophy, vfscore is unusually monolithic, bearing responsibility across many abstraction layers. | |
| #### Monolithic Nature | |
| Unlike most Unikraft core libraries, and counter to the unikernel philosophy, vfscore is unusually monolithic, bearing responsibility across many abstraction layers. |
Comment on lines
+59
to
+66
| To address vfscore's issues, as well as to lay the groundwork for future development, we introduce the Unikraft filesystem stack, anchored by two core libraries: | ||
| - `ukfs` - what is _a_ filesystem; driver registration & lookup | ||
| - `posix-vfs` what is _the_ filesystem (VFS); all userspace-facing operations |
Member
There was a problem hiding this comment.
Suggested change
| To address vfscore's issues, as well as to lay the groundwork for future development, we introduce the Unikraft filesystem stack, anchored by two core libraries: | |
| - `ukfs` - what is _a_ filesystem; driver registration & lookup | |
| - `posix-vfs` what is _the_ filesystem (VFS); all userspace-facing operations | |
| To address vfscore's issues, as well as to lay the groundwork for future development, we introduce the Unikraft filesystem stack, anchored by two core libraries: | |
| - `ukfs` - what is _a_ filesystem; driver registration & lookup | |
| - `posix-vfs` what is _the_ filesystem (VFS); all userspace-facing operations |
Comment on lines
+98
to
+106
| But with great power comes great responsibility, one that some drivers may not wish to burden themselves with; a non-exhaustive list of these responsibilities is: | ||
| - volume-wide state | ||
| - volume lifetime management |
Member
There was a problem hiding this comment.
Suggested change
| But with great power comes great responsibility, one that some drivers may not wish to burden themselves with; a non-exhaustive list of these responsibilities is: | |
| - volume-wide state | |
| - volume lifetime management | |
| But with great power comes great responsibility, one that some drivers may not wish to burden themselves with; a non-exhaustive list of these responsibilities is: | |
| - volume-wide state | |
| - volume lifetime management |
Comment on lines
+111
to
+120
| As part of this full-stack release, we introduced several new core libraries: | ||
| - `ukfs` -- filesystem API; compile-time driver registration; runtime driver lookup | ||
| - `ukfs-ramfs` -- memory-resident volatile filesystem |
Member
There was a problem hiding this comment.
Suggested change
| As part of this full-stack release, we introduced several new core libraries: | |
| - `ukfs` -- filesystem API; compile-time driver registration; runtime driver lookup | |
| - `ukfs-ramfs` -- memory-resident volatile filesystem | |
| As part of this full-stack release, we introduced several new core libraries: | |
| - `ukfs` -- filesystem API; compile-time driver registration; runtime driver lookup | |
| - `ukfs-ramfs` -- memory-resident volatile filesystem |
Signed-off-by: Andrei Tatar <ttr@unikraft.io>
andreittr
force-pushed
the
ttr/blog-vfs-0.20
branch
from
September 12, 2025 08:41
757d57c to
ca76124
Compare
Contributor
Author
|
Pushed update addressing comments. |
StefanJum
approved these changes
Sep 12, 2025
StefanJum
left a comment
Member
There was a problem hiding this comment.
All good, thanks.
Approved-by: Stefan Jumarea stefanjumarea02@gmail.com
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This blog post provides a technical overview of the new VFS stack introduced in Unikraft 0.20.0.