New OpenZFS port vcruntime and pool create

[dima333750]

Hi
I tested it https://www.lundman.net/OpenZFSOnWindows-debug-2.0.0-15-ga96cc4a70-dirty.exe
I found a couple of problems:

1. zpool at startup swears at the absence of
   vcruntime140d.dll ucrtbased.dll
   I managed to get around this problem I think I use copies of my files vcruntime140.dll ucrtbase.dll by renaming them to vcruntime140d.dll ucrtbased.dll
2. When you try to create a pool of zpool.exe create tank PHYSICALDRIVE4
   I get

Expanded path to '\\?\PHYSICALDRIVE4'
working on dev '\\?\PHYSICALDRIVE4'
this code assume FS is on partition 1 - tell lundman
cannot create 'tank': invalid argument for this pool operation

The disk definitely exists, but it doesn't see it
I also tried

fsutil file createnew G:\poolfile.bin 200000000
zpool create daddy \\?\G:\poolfile.bin

I get

cannot open '\\?\G:\poolfile.bin': no such device in \\?\
must be a full path or shorthand device name

[lundman]

I have already fixed vcruntime, and working on the pool create fix - broke it when I corrected import. Should have it better tomorrow I hope.

[dima333750]

Okay, I'll look forward to it.

[dima333750]

Hi
I tested it
https://www.lundman.net/OpenZFSOnWindows-debug-2.0.0-24-gdcdf6292f.exe

1. The vc runtime dependency has remained, and it requires:
   vcruntime140d.dll ucrtbased.dll

2. I was able to create a pool:
   zpool create -O compress=lz4 -O dedup=on -O casesensitivity=insensitive -O atime=off -o ashift=12 dedu PHYSICALDRIVE4

But when I started writing files I got a BSOD SYSTEM_SERVICE_EXCEPTION (3b)
Interestingly, I repeated 2-3 times and the BSOD occurred when writing 400-500mb
I attach the report
zfs_v2.txt

[lundman]

OK let's see:

 OpenZFS!zfs_vnop_lookup_impl+0x14bc [C:\src\openzfs\module\os\windows\zfs\zfs_vnops_windows.c @ 827] 

https://github.com/openzfsonwindows/openzfs/blob/windows/module/os/windows/zfs/zfs_vnops_windows.c#L827

	if (stream_name != NULL && vp != NULL) {
		// Here, we will release dvp, and attempt to open the xattr dir.
		// xattr dir will be the new dvp. Then we will look for streamname
		// in xattrdir, and assign vp.
		if (dvp_no_rele)
			VN_RELE(dvp);
		// Create the xattrdir only if we are to create a new entry
		if (error = zfs_get_xattrdir(VTOZ(vp), &dzp, cr, CreateFile ? CREATE_XATTR_DIR : 0)) {
==>			VN_RELE(vp);

Usually, "==>" points to what would-have next run, so we die with the prior line. But since we don't make it into zfs_get_xattrdir() that leaves VTOZ. But the if above confirms vp is not NULL. Odd.

vcruntime: Guess I need to find a dependency walker and see why it gets pulled in.

[lundman]

Hmm yes, it's pulling it in;:

[lundman]

Heh looks like I turned vcruntime off twice for C++ though, so, yep. 0bfe2d9

[lundman]

If you have time, can we check the stream panic with https://www.lundman.net/OpenZFSOnWindows-debug-2.0.0-26-g2f7bbd39c.exe -attempt to fix issue

[dima333750]

Hello

1. Dependency vcruntime defeated
2. BSOD remains, I attach a report, but the problem seems to be unchanged
   zfs_v2_2.txt

[dima333750]

Hello
I stretched
https://www.lundman.net/OpenZFSOnWindows-debug-2.0.0-26-g2f7bbd39c-dirty.exe
The problem remains, but there seems to be some change
zfs_v2_3.txt

[lundman]

What about today's version

[dima333750]

Hi My computer broke down and could not participate in testing, but I am back in service
Stretched https://www.lundman.net/OpenZFSOnWindows-debug-2.0.0-29-g35a90247c.exe
zfs_v2_4.txt

I got an error again, but it seems I started to understand how to reproduce the problem
you need to create a pool

zpool create -O compress=lz4 -O dedup=on -O casesensitivity=insensitive -O atime=off -o ashift=12 dedu PHYSICALDRIVE1
or
zpool create -O dedup=on -O casesensitivity=insensitive -O atime=off -o ashift=12 dedu PHYSICALDRIVE1

And copy to disk zip 7z or other compressed data (different and a lot of 100 mb +) and the problem manifests itself immediately.

I also noticed that when a pool is created, a folder with its name appears on the C: drive, and it is impossible to create a pool with this name again without deleting this folder. I don't know if it's a mistake or not ;)

[sskras]

@dima333750, are you still at it?

Maybe the BSOD got fixed in the meantime (and the issue could be closed).