I've faced with some performance issues developing my readonly filesystem using fskit. For below screenshot: enumerateDirectory returns two hardcoded items, compiled with release config 3000 readdirsync are done from nodejs. macos 15.5 (24F74) I see that getdirentries syscall takes avg 121us. Because all other variables are minimised, it seems like it's fskit<->kernel overhead. This itself seems like a big number. I need to compare it with fuse though to be sure. But what fuse has and fskit seams don't (I checked every page in fskit docs) is kernel caching. Fuse supports: caching lookups (entry_timeout) negative lookups (entry_timeout) attributes (attr_timeout) readdir (via opendir cache_readdir and keep_cache) read and write ops but thats another topic. And afaik it works for both readonly and read-write file systems, because kernel can assume (if client is providing this) that cache is valid until kernel do write operations on corresponding inodes (create, setattr, write, etc). Questions are: is 100+us reasonable overhead for fskit? is there any way to do caching by kernel. If not currently, any plans to implement? Also, additional performance optimisation could be done by providing lower level api when we can operate with raw inodes (Uint64), this will eliminate overhead from storing, removing and retrieving FSItems in hashmap.

I have my both app and fskit sandboxed &lt;key&gt;com.apple.security.app-sandbox&lt;/key&gt; &lt;true/&gt; Which means that I can read files only in app container. First, is sandboxing required for fskit modules? Second, there are docs which implies that it's possible to explicitly allow fskit module to access external files, by passing their paths to mount params. https://developer.apple.com/documentation/fskit/fstaskoptions/url(foroption:) and also options: Options to apply to the activation. These can include security-scoped file paths. There are no defined options currently. I've tried this, but haven't success. My Info.plist is &lt;key&gt;FSActivateOptionSyntax&lt;/key&gt; &lt;dict&gt; &lt;key&gt;shortOptions&lt;/key&gt; &lt;string&gt;g:m:&lt;/string&gt; &lt;key&gt;pathOptions&lt;/key&gt; &lt;dict&gt; &lt;key&gt;m&lt;/key&gt; &lt;string&gt;file&lt;/string&gt; &lt;key&gt;g&lt;/key&gt; &lt;string&gt;directory&lt;/string&gt; &lt;/dict&gt; &lt;/dict&gt; I'm mounting with mount -F -t MyFS -o -m=./build.sh,-g=./ /dev/disk5 /tmp/TestVol Getting them via options.url(forOption: "m"), options.url(forOption: "g") Both nulls. I also see that options are presented in options.taskOptions But they are not expanded to absolute pathes or urls, which makes me think that pathOptions declaration is incorrect. Docs says This dictionary uses the command option name as a key, and each entry has a value indicating what kind of entry to create. What entry kind means in this context? Can you send example of correct pathOptions?