# ZFS or other FS on SculptOS **URL:** \ **Category:** Genode and Sculpt OS\ **Created:** [January 25, 2026, 8:28pm UTC](https://genode.discourse.group/t/zfs-or-other-fs-on-sculptos/260 "2026-01-25T20:28:15Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![G0retZ](https://avatars.discourse-cdn.com/v4/letter/g/94ad74/32.png) [@G0retZ](https://genode.discourse.group/u/G0retZ)\ **Post date:** [January 25, 2026, 8:28pm UTC](https://genode.discourse.group/t/zfs-or-other-fs-on-sculptos/260/1 "2026-01-25T20:28:15Z")
I’d like to run Sculpt as NAS on my homelab (Intel Gen 9). And of course I want to have all the features ZFS provides for storage (RAID mirroring, snapshots etc.) I know that currently there is a commonly used [OpenZFS](https://openzfs.github.io) implementaion that is incorporated into FreeBSD system (in the kernel?) and as a loadable kernel module. My only experience of porting something somewhere is proting pjsip with opus codes to Android circa10 years ago, so I’m not very experienced with this field 🙃 Imagine I’d like to bring ZFS support to SculptOS, could you roughly outline what path would I need to walk through in order to port it? Also as a related question, what journey would challenge me if I’d like to add support to other filesystems like exFAT, XFS or EXT4? ---
**Author:** ![ttcoder](https://dub1.discourse-cdn.com/flex006/user_avatar/genode.discourse.group/ttcoder/32/9_2.png) [@ttcoder](https://genode.discourse.group/u/ttcoder)\ **Post date:** [January 26, 2026, 5:38pm UTC](https://genode.discourse.group/t/zfs-or-other-fs-on-sculptos/260/2 "2026-01-26T17:38:34Z")
Some quasi stream-of-consciousness items, waiting for someone to give better answers ^^: - I believe there is already support for ext4, possibly in the ‘genode-world’ repo instead of the main ‘genode’ repository - I seem to recall there is also a port of exFAT, but using an old (deprecated) Genode API, so you’d need to adapt it to new APIs before using it (it’s outlined in a genode-world ticket, probably one of the first tickets on the first page – edit : might be [this ticket](https://github.com/genodelabs/genode-world/issues/199)) - I’d start with something smaller first, maybe XFS indeed, before embarking on something like ZFS, which I hear is huge and is an “everything and the kitchen sink” FS, with deep dependancies into the Linux kernel (?), which would thus mean porting not just an FS but a whole lot of “stuff” on top of an FS - in Genode, file system support is provided simply by “FS plug-ins” – for instance a library called “vfs-fat.lib.so” (not the exact name, can’t recall ATM) is loaded into your vfs server, and bam, your vfs server supports fat. - in Genode, the vfs server (and thus its FS plugins) run in userland, making debugging of FS support easier - there is one difficulty when porting an FS though, even a ‘simple’ one like NTFS (let alone ZFS I assume) : the libc is not yet initialized at the time when the vfs server loads its plug-ins… So when porting e.g. XFS, you’d have to “re route” POSIX calls (like open(), close(), fstat(), read(), write()…). - That’s what was done to add NTFS support as an FS plug-in in the style of the new API (by opposed to the old Genode FS API) - edit : oh, there’s also the whole can of worms re., which FS _interface_ you want to use, to interface with Genode. Some FS ports use the FUSe (File User in Userspace) interface, heck, I’ve even been known to port BFS, using a ‘port’ of the BeOS kernel file-system interface, so that I would then (in theory) get others Be FS ports “for free”, including their port of XFS… But I’m probably going into the weeds here… FUSe is a solid standard, for its part. ---
**Author:** ![G0retZ](https://avatars.discourse-cdn.com/v4/letter/g/94ad74/32.png) [@G0retZ](https://genode.discourse.group/u/G0retZ)\ **Post date:** [January 27, 2026, 9:08am UTC](https://genode.discourse.group/t/zfs-or-other-fs-on-sculptos/260/3 "2026-01-27T09:08:51Z")
Thanks for your input! Now I see, that this topic doesn’t seem an easy one and adding FS support is not straightforward 😅 ---
**Author:** ![jws](https://dub1.discourse-cdn.com/flex006/user_avatar/genode.discourse.group/jws/32/104_2.png) [@jws](https://genode.discourse.group/u/jws)\ **Post date:** [January 27, 2026, 11:17am UTC](https://genode.discourse.group/t/zfs-or-other-fs-on-sculptos/260/4 "2026-01-27T11:17:48Z")
As @ttcoder’s list nicely demonstrates, there are a few considerations to make when dealing with file-systems on Genode (although that is also true on other OSes because there is always some form of VFS involved). So let’s start with a brief overview of the architecture (that will contain a decent amount of technical details to give you starting points for exploration): There is the _File system_ session (_os/include/file\_system\_session_) that is implemented by the various server components, most prominently the `vfs` (_os/src/server/vfs_) server and used by client components to access a given file-system. Internally this server makes use of the VFS `vfs.lib.so` (_os/include/vfs_ and _os/src/lib/vfs_) provided as shared-library to assemble the file-system it exports to its clients. This library is also used for providing component-local VFS instances, like in components making use of the C library. The VFS itself already contains internal plugins, e.g. `fs` that can be used to access another _File system_ server, but can be extended through external plugins (also shared-libraries) as well, like `vfs_rump.lib.so` (_dde\_rump/src/lib/vfs/rump_) for providing ext2 support via NetBSD’s rumpkernel. _vfs\_rump_ in return uses the _Block_ session directly (_dde\_rump/src/lib/rump/io.cc_) to access the underlying storage device. > [@ttcoder](#): > > I believe there is already support for ext4, possibly in the ‘genode-world’ repo instead of the main ‘genode’ repository I used [lwext4](https://github.com/gkostka/lwext4) to implement the [vfs\_lwext4](https://codeberg.org/jws/genode-wundertuete/src/branch/25.05-2025-07-07) plugin but at this point I would consider it to be in _“maintainance-mode”_. That being said, in contrast to _vfs\_rump_ it accesses the _Block_ session via the VFS `block` plugin. As you may have noticed, one of the purposes of the VFS is to provide access to Genode’s services through file I/O mechanics, e.g. _/dev/block_ serves the same purpose as _/dev/sda1_ on other OSes. So… to bring support for a new file-system to Genode—your mission, should you choose to accept it—would be to write a new VFS plugin. As the context in which a VFS plugin operates is constrained, making use of the C library file I/O, as is commonly done in FUSE based file-systems, not possible (as of now) and porting such file-system implementation can be difficult (more on that later). > [@G0retZ](#): > > Imagine I’d like to bring ZFS support to SculptOS, could you roughly outline what path would I need to walk through in order to port it? > > Also as a related question, what journey would challenge me if I’d like to add support to other filesystems like exFAT, XFS or EXT4? _(As a long-time ZFS user myself, having it on Genode would be awesome—so you are not alone with that desire 😉.)_ Well, porting ZFS will be quite involved, as in _“it is a marathon not a sprint”_. On the one hand you have to port the file-system driver, i.e., the _kmod_ (implement the SPL (_Solaris Porting Layer_) to interface with the OpenZFS code), and on the other hand you have to port the tools, like _zdb_, _zpool_ and _zfs_, and have to make them work with each other. Which brings my to the second part of your quote: Since the upstream implementation of ext4 is maintained within Linux (for obvious reasons), using the DDE Linux approach (providing a _Genode C API_ for the _File system_ session and “carving” out Linux’ VFS-layer plus ext4) to port it over feels natural and is the direction I would take. The added benefit is (potentially) easier access to other file-systems as well in the future, i.e., when the first ported Linux file-systems works sufficiently, getting additional ones should require less effort. That would also include ZFS: we would ride piggy-back on the SPL implementation of OpenZFS on Linux. That being said, this is still _involved_, which is why I would not recommend that as a spare time project. However, I found creating a minimal FUSE implementation (still available in [world/legacy](https://github.com/genodelabs/genode-world/tree/master/legacy) but more or less left untouched besides some kneading by @ttcoder 😄) for Genode and porting a few selected FUSE file-systems over some years ago rewarding. If you want to get your toes wet in that regard, I think looking into, for example, _fuse-exfat_ and creating a `vfs_exfat` plugin based on _libexfat_ might be a more approachable exercise. _IIRC_ the API is similar to _lwext4_ and thus `vfs_lwext4` could serve as a blueprint. Looking into _fuse-exfat_ should demonstrate what _libexfat_ API calls you would have to make in the VFS plugin’s implementation. The block I/O calls warrant some consideration but these could be implemented within the plugin (again, similar to how _vfs\_lwext4_ provides some C library functions). * * * In the interm, running ZFS in a VM on top of Sculpt OS might be a workable stop-gap solution and could play nicely in the _headless-server_ Sculpt OS variant others talked about during the roadmap discussion. ---
**Author:** ![G0retZ](https://avatars.discourse-cdn.com/v4/letter/g/94ad74/32.png) [@G0retZ](https://genode.discourse.group/u/G0retZ)\ **Post date:** [January 27, 2026, 11:25pm UTC](https://genode.discourse.group/t/zfs-or-other-fs-on-sculptos/260/5 "2026-01-27T23:25:34Z")
Thank you a lot @jws for such a thorough explanation! 🙏 Indeed this sound more like a marathon than a walk through the block 😅 It feels I need to learn quite a bit before making a step into first attempt. But at least I have a rough idea of what would it take to achieve the goal 👍 I don’t think I have time to start this journey at the moment, but I will post updates once I will dare to start it. 👌