While running trinity within a user mode linux image which has the same BTRFS filesystem from the host mounted both via NFS and hostfs (that FS itself was created within a file at a ramdisk at the host side) I observed from my control script these messages : rm: cannot remove ‘/mnt/trinity/w/inux’: No space left on device rm: cannot remove ‘/mnt/trinity/w/$’: No space left on device rm: cannot remove ‘/mnt/trinity/w/\211\271\271\340\340\211\211\271\271\340\340\211\211\271\271\340\340\211\211\271\271\340\340\211\211\271\271\340\340\211\211\271\271\340\340\211\211\271\271\340\340\211\211\271\271\340\340\211\n\277’: No space left on device rm: cannot remove ‘/mnt/trinity/w/\020’: No space left on device mkdir: cannot create directory ‘/mnt/trinity/w’: File exists chmod: changing permissions of ‘/mnt/trinity/v/victims’: No space left on device chmod: changing permissions of ‘/mnt/trinity/v/victims/d01’: No space left on device Well, the file system is full: $> df -m ... /dev/loop0 257 245 9 97% /mnt/trinity but why does rm fail with that messages ? And chmod too ? FWIW host kernel is 3.8.9, UML guest runs 3.9-rc8-..., OS is Gentoo stable at each system. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
