You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, w.r.t. superblock handing is this to create / parse / read the FS metadata only (aka equivalent of reading or possibly even writing data as it is seen after mkfs.xfs)?
Or can one also populate files?
I have been looking for anything that can write out xfs filesystem, without using a Linux kernel (and mounting a filesystem).
The text was updated successfully, but these errors were encountered:
For now we're prioritising superblock detection. However as seen in luks2 we're planning to go further. Eventually I'd like opt-in std and write support for a number of filesystems and pull in the superblock crate for their data definitions.
First one will be erofs and maybe we can get the design right there then extend.
I think log and cache bits will fail to consumer domain and exposed / integrated via crate.
If I grok, you're looking to build complete filesystem images as euid!= 0 and bypass loop entirely?
And yes, the dream is to be able to built filesystem / VM images, unprivileged, like one can do today for most part to build containers / .deb / .rpm / well they all are just tarballs more or less.
Hi, w.r.t. superblock handing is this to create / parse / read the FS metadata only (aka equivalent of reading or possibly even writing data as it is seen after mkfs.xfs)?
Or can one also populate files?
I have been looking for anything that can write out xfs filesystem, without using a Linux kernel (and mounting a filesystem).
The text was updated successfully, but these errors were encountered: