grahamwhaley
commented
6 years ago Hi @AlanWarwick Thanks for the report.
Yes, this is a limitation of 9p I'm afraid. Over in the kernel source it can be seen that there is no .fallocate handler in the 9p file system handler structs to process the request.
As that is a fundamental issue at the 9p kernel driver level, it's not something Kata can fix easily, and there is nothing on the Kata roadmap right now afaik to see if the 9p protocol and file system could be extended to add this case.
There is an alternative you can use with Kata to avoid 9p and thus the issue. If you set up docker to use a block capable graph driver for its storage (such as devicemapper, as documented by docker here), then Kata can mount the container fs into the VM as a block device rather than using 9p, and this should then give you the capabilities you need.
@amshinde will soon be writing up how a guide to this. An easy way to check how the container fs is mounted is to run a mount inside the container itself, and see if you can see a 9p or sda block device mount for the root folder.
Any issues, do ask back here.
Description of problem
I have an app that uses preallocated files and also sparse files and have found that there are a set of syscalls that are not supported when running in a kata container using the 9pfs file system. Specifically the syscalls are:
fallocate
ioctl(FS_IOC_FIEMAP)
when calling these I get errno EOPNOTSUPP
Expected result
Expect these syscalls to be implemented
Actual result
errors are returned - EOPNOTSUPP
kata-collect-data.log