OverlayFS/UnionFS #27

New Issue

2020-01-31T08:52:47-05:00

Nerdpie commented

2020-01-31 08:52:47 -05:00

(Migrated from github.com)

I would like to have Opus installed via a resource/data pack so that I don't have to manually install it on each computer (bonus: more space on each device). The biggest issue with doing so, however, is that many files are then read-only. As a possible solution, we could have something akin to OverlayFS or UnionFS, which are used to load data (settings, user files, etc.) on top of an otherwise read-only system, such as a LiveCD. I've thought about a few points, but I haven't dug into the VFS module enough to implement it myself at this time.

Use a hidden top-level folder for the overlay data. Data would likely mimic the paths being mapped, e.g. /.overlay/sys/etc/fstab
Treat all nodes as read-write
Expose a method to check if the underlying node is actually read-write, such that tools like minify and lzwfs don't end up using MORE space.

In my use case of an Opus data pack, there are a couple of extra considerations:

Files earlier in 'boot' than the VFS module won't be able to be edited; in my particular use case (single-player), this isn't an issue, but for servers, it will be of concern.
Server owners might be expected to keep the pack up-to-date, which may cause issues (delayed updates; players updating their specific computer, resulting in breakage from mismatched versions; etc.).

I would like to have Opus installed via a resource/data pack so that I don't have to manually install it on each computer (bonus: more space on each device). The biggest issue with doing so, however, is that many files are then read-only. As a possible solution, we could have something akin to OverlayFS or UnionFS, which are used to load data (settings, user files, etc.) on top of an otherwise read-only system, such as a LiveCD. I've thought about a few points, but I haven't dug into the VFS module enough to implement it myself at this time. - Use a hidden top-level folder for the overlay data. Data would likely mimic the paths being mapped, e.g. `/.overlay/sys/etc/fstab` - Treat all nodes as read-write - Expose a method to check if the underlying node is actually read-write, such that tools like `minify` and `lzwfs` don't end up using MORE space. In my use case of an Opus data pack, there are a couple of extra considerations: - Files earlier in 'boot' than the VFS module won't be able to be edited; in my particular use case (single-player), this isn't an issue, but for servers, it will be of concern. - Server owners might be expected to keep the pack up-to-date, which may cause issues (delayed updates; players updating their specific computer, resulting in breakage from mismatched versions; etc.).

xAnavrins commented

2020-02-10 15:40:16 -05:00

(Migrated from github.com)

https://pastebin.com/3AnVT3Ec
This is a script that will download the whole OS into a kind of ramfs, while the OS files downloaded are read-only, the /usr folder will not, so your configs and other things will persist through reboots.

https://pastebin.com/3AnVT3Ec This is a script that will download the whole OS into a kind of ramfs, while the OS files downloaded are read-only, the /usr folder will not, so your configs and other things will persist through reboots.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MayaTheShy/Opus#27