4 ms·

I wrote a tool to do this many years ago on the Xbox 1 (the original) to avoid having to use loopmounted files, but it's not the kind of thing you want to rely

I wrote a tool to do this many years ago on the Xbox 1 (the original) to avoid having to use loopmounted files, but it's not the kind of thing you want to rely on for a modern filesystem like APFS. There's no way to guarantee that the OS won't mess with your data, move it elsewhere, etc (and if it doesn't today, it might in tomorrow's macOS update). I would never trust this approach enough to recommend it for our users, to be honest.

derefr 5y ago
> There's no way to guarantee that the OS won't mess with your data, move it elsewhere, etc I mean, "moving it elsewhere" is why you'd call into linux-apfs on every boot — to find out where the rootfs backing file's extent is living today. It might move around between boots, but it won't move while macOS isn't even running. And this approach presumes that there exists an explicit file attribute for keeping a file single-extent / contiguous-on-disk (as far as the host-NVMe interface is concerned, at least.) Such an attribute does exist on NTFS, which is why WUBI continued to work there. I've never heard about such an attribute existing on APFS, which is why I said I'm not sure whether APFS "supports" this. Usually there is such an attribute in most-any filesystem, though — it exists to be used with swap files, so that kernels can directly mmap(2) the disk-block range underlying the swap file rather than having every read/write go through the filesystem layer. I know that macOS uses an APFS volume for swap (the "VM" volume), which is kind of interesting. Maybe in APFS, there isn't a per-file attribute for contiguous allocation, but rather a per-volume one? In that case, it might be possible for the Linux rootfs to be an APFS volume, in the same way that the macOS VM volume is an APFS volume.
- marcan_42 5y ago
  > I've never heard about such an attribute existing on APFS, which is why I said I'm not sure whether APFS "supports" this. Ah, yeah, I've never heard of anything like that. I didn't realize NTFS had this. I have no idea how APFS handles the VM volume, though.

derefr 5y ago

> There's no way to guarantee that the OS won't mess with your data, move it elsewhere, etc I mean, "moving it elsewhere" is why you'd call into linux-apfs on every boot — to find out where the rootfs backing file's extent is living today. It might move around between boots, but it won't move while macOS isn't even running. And this approach presumes that there exists an explicit file attribute for keeping a file single-extent / contiguous-on-disk (as far as the host-NVMe interface is concerned, at least.) Such an attribute does exist on NTFS, which is why WUBI continued to work there. I've never heard about such an attribute existing on APFS, which is why I said I'm not sure whether APFS "supports" this. Usually there is such an attribute in most-any filesystem, though — it exists to be used with swap files, so that kernels can directly mmap(2) the disk-block range underlying the swap file rather than having every read/write go through the filesystem layer. I know that macOS uses an APFS volume for swap (the "VM" volume), which is kind of interesting. Maybe in APFS, there isn't a per-file attribute for contiguous allocation, but rather a per-volume one? In that case, it might be possible for the Linux rootfs to be an APFS volume, in the same way that the macOS VM volume is an APFS volume.

marcan_42 5y ago
> I've never heard about such an attribute existing on APFS, which is why I said I'm not sure whether APFS "supports" this. Ah, yeah, I've never heard of anything like that. I didn't realize NTFS had this. I have no idea how APFS handles the VM volume, though.