Skip to content

blog: Add blog post on new vfs stack - #520

Merged
StefanJum merged 1 commit into
unikraft:mainfrom
andreittr:ttr/blog-vfs-0.20
Sep 12, 2025
Merged

blog: Add blog post on new vfs stack#520
StefanJum merged 1 commit into
unikraft:mainfrom
andreittr:ttr/blog-vfs-0.20

Conversation

@andreittr

Copy link
Copy Markdown
Contributor

This blog post provides a technical overview of the new VFS stack introduced in Unikraft 0.20.0.

@razvand razvand left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All good, thanks.

Reviewed-by: Razvan Deaconescu razvand@unikraft.io

@StefanJum StefanJum left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Pushed update addressing comments.

@StefanJum StefanJum left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All good, thanks.

Approved-by: Stefan Jumarea stefanjumarea02@gmail.com

@StefanJum
StefanJum merged commit 6acb5e0 into unikraft:main Sep 12, 2025
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants