UFS filesystem giving no free inode error in Azure ARM64 preview image. I am trying to create directory named sandbox in /datadrive, which is having ufs fs and block device. Running truss I can get following: [schakrabarti@arm-freebsd-schakrabarti2 /datadrive]$ truss mkdir sandbox mmap(0x0,135168,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 81664290062336 (0x4a45f3000000) mprotect(0x7b822f39e000,4096,PROT_READ) = 0 (0x0) issetugid() = 0 (0x0) sigfastblock(0x1,0x7b822f3afe00) = 0 (0x0) open("/etc/libmap.conf",O_RDONLY|O_CLOEXEC,01) = 3 (0x3) fstat(3,{ mode=-rw-r--r-- ,inode=35954,size=47,blksize=32768 }) = 0 (0x0) read(3,"# $FreeBSD$\nincludedir /usr/loc"...,47) = 47 (0x2f) close(3) = 0 (0x0) open("/usr/local/etc/libmap.d",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,053) ERR#2 'No such file or directory' open("/var/run/ld-elf.so.hints",O_RDONLY|O_CLOEXEC,010441603537) = 3 (0x3) read(3,"Ehnt\^A\0\0\0\M^@\0\0\0k\0\0\0\0"...,128) = 128 (0x80) fstat(3,{ mode=-r--r--r-- ,inode=37902,size=235,blksize=32768 }) = 0 (0x0) pread(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,107,0x80) = 107 (0x6b) close(3) = 0 (0x0) open("/lib/libc.so.7",O_RDONLY|O_CLOEXEC|O_VERIFY,010441603540) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=36538,size=1892592,blksize=32768 }) = 0 (0x0) mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,3,0x0) = 55885151227904 (0x32d3c6965000) mmap(0x0,4341760,PROT_NONE,MAP_GUARD,-1,0x0) = 55885163905024 (0x32d3c757c000) mmap(0x32d3c757c000,565248,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x0) = 55885163905024 (0x32d3c757c000) mmap(0x32d3c7615000,1269760,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x89000) = 55885164531712 (0x32d3c7615000) mmap(0x32d3c775a000,40960,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0x1be000) = 55885165862912 (0x32d3c775a000) mmap(0x32d3c7773000,28672,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0x1c7000) = 55885165965312 (0x32d3c7773000) mmap(0x32d3c777a000,2252800,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 55885165993984 (0x32d3c777a000) munmap(0x32d3c6965000,4096) = 0 (0x0) close(3) = 0 (0x0) mprotect(0x32d3c775a000,36864,PROT_READ) = 0 (0x0) readlink("/etc/malloc.conf",0x32d3c56a52cc,1024) ERR#2 'No such file or directory' issetugid() = 0 (0x0) mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(21),-1,0x0) = 81664292159488 (0x4a45f3200000) mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 81664294256640 (0x4a45f3400000) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(21),-1,0x0) = 81664296353792 (0x4a45f3600000) /datadrive: create/symlink failed, no inodes free mkdir("sandbox",0777) ERR#28 'No space left on device' mkdir: write(2,"mkdir: ",7) = 7 (0x7) sandboxwrite(2,"sandbox",7) = 7 (0x7) : write(2,": ",2) = 2 (0x2) issetugid() = 0 (0x0) fstatat(AT_FDCWD,"/usr/share/nls/C/libc.cat",0x32d3c56a6470,0x0) ERR#2 'No such file or directory' fstatat(AT_FDCWD,"/usr/share/nls/libc/C",0x32d3c56a6470,0x0) ERR#2 'No such file or directory' fstatat(AT_FDCWD,"/usr/local/share/nls/C/libc.cat",0x32d3c56a6470,0x0) ERR#2 'No such file or directory' fstatat(AT_FDCWD,"/usr/local/share/nls/libc/C",0x32d3c56a6470,0x0) ERR#2 'No such file or directory' No space left on device write(2,"No space left on device\n",24) = 24 (0x18) exit(0x1) process exit, rval = 1 The df output [schakrabarti@arm-freebsd-schakrabarti2 /datadrive]$ df -h Filesystem Size Used Avail Capacity Mounted on /dev/gpt/rootfs 29G 3.4G 23G 13% / devfs 1.0K 0B 1.0K 0% /dev /dev/gpt/efiesp 32M 842K 31M 3% /boot/efi /dev/da2p1 992G 8.0K 912G 0% /datadrive /dev/da1p1 579G 8.0K 533G 0% /mnt/resource [schakrabarti@arm-freebsd-schakrabarti2 /datadrive]$ mount /dev/gpt/rootfs on / (ufs, local, soft-updates) devfs on /dev (devfs) /dev/gpt/efiesp on /boot/efi (msdosfs, local) /dev/da2p1 on /datadrive (ufs, local, soft-updates) /dev/da1p1 on /mnt/resource (ufs, local, soft-updates)
I suspect that this is the same issue as bug267654. Can you check the dmesg?
(In reply to Li-Wen Hsu from comment #1) Yes, it is same. I will mark it as duplicate. *** This bug has been marked as a duplicate of bug 267654 ***