Code review comment for ~paul-meyer/cloud-init:fix-ntfs-mount

Revision history for this message
Scott Moser (smoser) wrote :

I kind of suspect that mount.ntfs would do a modprobe. That seems quite reasonable to me.

that said... There is a ton of happenstance here. I realize that most likely if you have an ntfs filesystem on azure and you can't mount it, then you probably didnt have any data there.

However, there is a failure case. However unlikely..
a.) boot into ubuntu with ntfs support, put a ton of important data on a disk that warns clearly that it is not to be used for important data.
b.) install a custom kernel
c.) reboot
d.) cloud-init can't mount ntfs, so it assumes it should create a new filesystem there.
e.) user screams, and angry tweets about how irresponsible cloud-init developers are, especially @smoser0.

yes... its probably very unlikely.

Better would be if we had information exposed to us from the platform (Azure) that said definitively "we wiped that disk... its empty now".

Without access to that fact, which is known to the platform, we're just doing a bunch of heuristics.

I'm almost more apt to just say that on azure, cloud-init will *always* feel free to destroy an ntfs partition. At least then, we've fixed the problem for the future... no one will ever have an ntfs filesystem there that they put their data on. We can make a config option saying "never-destroy-ntfs" for those people that for some reason did that intentionally, or we can just tell them that there might be better choices for a filesystem.

« Back to merge proposal