Open qooxzuub opened 2 weeks ago
I disabled the check when mounting read-only, and then it mounts the disk.
diff --git a/super.c b/super.c
index 8fe9fac..8151e01 100644
--- a/super.c
+++ b/super.c
@@ -1329,8 +1329,13 @@ static int apfs_check_vol_features(struct super_block *sb)
return -EINVAL;
}
if (features & APFS_INCOMPAT_DATALESS_SNAPS) {
- apfs_warn(sb, "snapshots with no data are not supported");
- return -EINVAL;
+ apfs_warn(sb, "snapshots with no data are not supported...");
+ if (!sb_rdonly(sb)) {
+ apfs_warn(sb, "...disallowing rw mount");
+ return -EINVAL;
+ } else {
+ apfs_warn(sb, "...attempting to proceed with ro mount");
+ }
}
if (features & APFS_INCOMPAT_ENC_ROLLED) {
apfs_warn(sb, "encrypted volumes are not supported");
So far all seems to be fine.
That's interesting. I've never encountered "dataless snapshots" (no idea what they are), but the official documentation says that you are not supposed to mount them even on read-only mode from a driver that doesn't support them. How did you make this filesystem? I could add support for real if I had an image.
I am dual-booting High Sierra with linux, and that is my main OS X partition. The partition was shrunk in the last couple of months using diskutil in OS X to allow me to install linux. It is on an SSD which was cloned a few years ago from the HDD that came with the machine in 2011. The HDD would have had some version of OS X pre-installed on it.
It might be relevant that I have occasionally manually freed up disk space using tmutil thinlocalsnapshots
in OS X.
Hopefully mounting read-only will never alter any bits on the disk? I'd rather not risk corruption on that partition...
Read-only won't alter anything, the only risk is that some things might not be read correctly.
I have occasionally manually freed up disk space using tmutil thinlocalsnapshots
That could have something to do with it, I guess. I'll try and see what happens.
By the way, when I run tmutil listlocalsnapshots /
in OS X, I see three snapshots and none of them are marked as dataless. Based on this I would expect any dataless snapshots to be marked. So it's possible that, despite the error from apfs.ko, I have no dataless snapshots.
I guess the flag gets set when the first dataless snapshot is created, and then it just never gets unset.
I still haven't figured out how to create dataless snapshots on macos. It's easy to use my driver to make snapshots that macos identifies as "dataless", but I'm not sure if they are correct.
I just built the module from the github source and used insmod to put it in the kernel.
I get this in dmesg
APFS (800002g): snapshots with no data are not supported
when running
$ sudo mount -o vol=0 /dev/sda2 /tmp/mnt mount: /tmp/mnt: wrong fs type, bad option, bad superblock on /dev/sda2, missing codepage or helper program, or other error. dmesg(1) may have more information after failed mount system call.
I believe volume 0 on /dev/sda2 is the correct information. Maybe the error message indicates that I should give a snap=label option to mount? If that is correct, how do I find the snapshot label to provide? I want to mount the "current" snapshot, i.e., the one I see from OS X by default.
(For comparison, fsapfsmount -v -X ro -f 1 /dev/sda2 OS\ X\ disk/ mounts the volume, although it seems that an old snapshot is mounted rather than the current one as new files created in OS X do not appear.)