Deep mkdir fails about zfs HOT 6 CLOSED

Two things, it turns out that our negative-cache seems to override the mkdir made after. We should update the cache after mkdir (presumably by removing the negative cache). For now, I have disabled negative cache entries;
openzfsonosx/spl@dc86dc2

The second thing is when vnop_lookup is called, the kernel optimises by using the full path in part lookups. With "/alpha/beta/gamma/" it would set componentname to "beta/gamma/" with namelen of 4, to look up only "beta". We need to copy the name out and null terminate. (or add namelen argument to dir_lookup).
c4ac791

from zfs.

Even though I fixed two issues, there is a third, and quite rare. Needs looking at as well.

from zfs.

Hmm, can you tell a bit more on how the third issue manifests itself?

from zfs.

It is a bit unfortunately that two unrelated problems would produce the same (or at least similar) errors in rsync.

One was that we have to pay attention to namelen in component name, so directories created 2 (or more) levels down (ie, lookup containing slashes "alpha/beta") would appear to not exist right after mkdir.

and second is negative caching. I don't fully understand why entering a negative cache for a dir, then we call mkdir, and the negative cache still exists. The comments in MacZFS implies VFS layer adds the mkdir entry to cache. But I did not look deeper into this. I do suspect that verifying the dnlc wrappers to cache_ calls might be in order.

Similarly, 3rd case do also happen, if even more infrequently, large rsync (like that of the zfs.osx zfs directory) or running bonnie will trigger it.

I have not yet run truss on it (which is how I worked out the previous cases, to see that stat("alpha"); mkdir("alpha") ; cd("alpha") would fail)

# ./bonnie++ -u root -d /BOOM/ -s 20 -n 100:1024:0:50 -r 10 -f
Using uid:0, gid:0.
Writing intelligently...done
Rewriting...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...
Can't write data.
Cleaning up test directory after error.

or rsync

bash-3.2# rsync -ar ./ /BOOM/
rsync: chown "/BOOM/lib/libuutil/.uu_ident.lo.QdUfwX" failed: Cannot allocate memory (12)

from zfs.

Pretty hard to track down, but most likely this:

 2994/0x28454:  open_nocancel("cmd/zpool/.Makefile.in.cTEvq4\0", 0xA02, 0x180)           = 1 0^M
 2994/0x28454:  fchmod(0x1, 0x180, 0x0)          = 0 0^M
 2994/0x28454:  fcntl(0x1, 0x30, 0x1)            = 0 0^M
 2994/0x28454:  fcntl(0x1, 0x2A, 0x7FFF50CD5B00)                 = 0 0^M
 2994/0x28454:  fchmod(0x1, 0x180, 0x0)          = -1 Err#12^M
 2994/0x28454:  unlink("cmd/zdb/.zdb_il.c.3fzcFd\0", 0x1, 0x0)           = 0 0^M

Which would imply we fail at chmod sometimes.

from zfs.

It turns out that returning 0 (OK) for the getxattr and setxattr isn't a good idea when we don't have the code for it yet.
5099767

Closing again as rsync runs without warnings.

Negative-caching was never a problem, handled correctly by VFS layer.

from zfs.