sommerfeld: I feel like an NFS close() might implicitly become an fsync() on the file server?

If you did, via NFS, a truncate and some writes and a close, then the file server was interrupted in that window, I could see this happening

The same question should be asked of SMB/CIFS too, just in case.

I haven't known this answer since .nfs<blahblah>

but my immediate thought was the XFS port to linux, that had a habit of replacing your data with \0 for years.

it was very strict about the _metadata_ being entirely correct on disk, but when it got sad your data was not

Anyone ever seen this from one of the zvol tests? paste.omnios.org/?a0b1b22b0dcb8e78#…yUFmQ6k9KEiM59x93ckofJGeuDKnj8xkngi

It has made me realise that the zvol_misc cleanup is not robust enough

I've years of test runs now. Lemme run some tools...

Only found one failure there. Gist coming soon...

I am just checking it's not related to the ZFS change I'm testing. Can't see how it is

Doesn't look like it... the directory I literally labelled WTF, suggesting I screwed up something. Can check notes too..

Ok, thanks for checking. I'll look at the core.

.. okay my WTF was a case of "apparently zpool export testpool was not yet done… ". (Thanks to @tsoome for that diagnosis back in April.)

There are definitely some opportunities for improvement in this. In my case that failed pool creation (which was expected to fail but not like that) left the pool used as a dump device and broke all of the subsequent tests.

i don't recognize that one, but it's been a while since i've run any zfs tests

and yeah, there were several errors (I think tsoome might have fixed at least a few of them) where some tests didn't clean up properly which lead to subsequent tests to fail (but would succeed when you re-ran them since the earlier tests that passed weren't re-run)

Well it's reproducible, so I just need to find where in ZFS land the EDOM is coming from.

fortunately you can track SET_ERROR ;)

maybe a channel program?

It's a brand new VM I just set up for running the zfs testsuite. I'll look into it.

hm. if you `mkdir("/dev/zvol/rdsk/", ...)` you get an ENOSYS. that really feels like it should be an EEXIST, no?

i haven't looked all that much, just enough to see that vn_createat gets all the way to fop_mkdir and ENOSYS comes from fs_nosys, but that seems pretty late for a path that clearly exists!

That will get handled by the dynamic plugin in sdev.

you mean that changing this would end up in sdev_zvolops.c, right? i also notice that it gets past lookuppnat without an error, which seems curious. but if the ENOSYS seems remarkable i'll at least open an issue