Errors creating a canister with 'dfx deploy'

Developers
21

Hi

I believe so - though I’m not sure for certain. I only have that one main partition - one other I used for bootcamp years back but don’t any more. I only have one disk I run things from.

Here’s the output anyway.

df:

Filesystem    512-blocks      Used Available Capacity iused      ifree %iused  Mounted on
/dev/disk0s2   896968952 838871840  57585112    94% 2401398 4292565881    0%   /
devfs                365       365         0   100%     632          0  100%   /dev
map -hosts             0         0         0   100%       0          0  100%   /net
map auto_home          0         0         0   100%       0          0  100%   /home
/dev/disk0s4    78123000  63580208  14542792    82%  110734    7349334    1%   /Volumes/BOOTCAMP

diskutil list:

   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Matt's Mac              459.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:       Microsoft Basic Data BOOTCAMP                40.0 GB    disk0s4
22

Hi @canicodenow!

I’m Roman, I authored most of the replica state snapshotting code.

Thanks a lot for reporting the issue! I’m sorry that your first experience with the replica wasn’t great at all. The replica was designed to work on any modern UNIX. Unfortunately, we haven’t tested it on HFS+ file system. Until today.

I was able to reproduce the issue you see by formatting a drive as HFS+ and running dfx on it. The patch with the fix is on the way!

Boring technical details

The error happens when the replica tries to create a snapshot of its state so that it doesn’t have to execute all the blocks from scratch if it restarts. The replica tries to leverage file cloning capabilities provided by modern filesystems to make snapshotting blazingly fast. If the filesystem doesn’t support that feature (few do), we fallback to standard file copying. What you observe is a bug in the fallback mechanism: if the file cloning syscall fails, Linux kernel returns EOPNOTSUPP error code, while macOS returns ENOTSUP. We handle the former but not the latter (it’s easy to confuse them, they are actually equal on Linux, but not on macOS), so the fallback code doesn’t work properly on macOS. The fix is a one-line code change here.

I’ll do my best to make sure that the next release of dfx includes a replica that works fine on your system. Please use the emulator option suggested by @prithvi until then.

Looking forward to seeing all the great things you’ll build on the Internet Computer.

Roman

7 Likes
23

Hi @roman-kashitsyn and thank you for looking into it.

I’m amazed that I’ve come across a unique problem but glad it looks like a straightforward fix. In the meantime I’ll use the emulator option.

I’ll come back after the patch to let you know if it’s all working or not.

Matt