Cannot correctly write to filesystems mounted in a folder

qinq-net commented 2 years ago

System information

Type	Version/Name
Distribution Name	Windows 10
Distribution Version	21H2
OpenZFS Version	zfs-2.0.0-2 zfs-kmod-fixme OpenZFSOnWindows-debug-2.1.99-968-g32152cd8a-dirty.exe

Describe the problem you're observing

If I import a pool with multiple filesystems, and mount them all, it should work like the common Unix filesystem tree. However, when I mount a sub-filesystem without a separate driveletter, it appears that I am still writting to the father filesystem, while reading the daughter filesystem. This causes a dismatch. If I use Windows Explorer to create a file, it freezes.

Describe how to reproduce the problem

Create a filesystem under the root filesystem without a separate driveletter. Mount them all. Go to the daughter filesystem mountpoint, and try to create folders/files.

A sample is in this vhd file. https://1drv.ms/u/s!AuQw0vPQfcODkoBgsS5g7tbBqe07mA?e=wO6Bm6

In the above file, there is a pool named zfs-test-tank on the 2nd visible partition (not considering MSR). The root filesystem is set to driveletter=F, while the daughter filesystem zfs-test-tank/test2 does not. I tried to create a folder named test3 under `test2', but it was created in the mountpoint folder on the father filesystem.

Include any warning/errors/backtraces from the system logs

PS C:\WINDOWS\system32> zpool import -N zfs-test-tank
#### some physical disks ####
path '\\?\scsi#disk&ven_msft&prod_virtual_disk#2&1f4adffe&0&000002#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}'
 and '\\?\PhysicalDrive2'
read partitions ok 3
    gpt 0: type f915dad0 off 0x4400 len 0xffbc00
    gpt 1: type f915dad0 off 0x1000000 len 0x40000000
    gpt 2: type f915dad0 off 0x41000000 len 0x3ee00000
asking libefi to read label
EFI read OK, max partitions 128
    part 0:  offset 22:    len 7fde:    tag: 10    name: 'Microsoft reserved partition'
    part 1:  offset 8000:    len 200000:    tag: 11    name: 'Basic data partition'
    part 2:  offset 208000:    len 1f7000:    tag: 11    name: 'Basic data partition'
#### some physical disks ####
#### some other volumes ####
Processing volume '\\?\Volume{9ba2afda-2c42-4ac3-8ead-6982e384f1b3}'
#### some other volumes ####
setting path here '/dev/Harddisk2Partition3'
setting physpath here '\\?\Volume{9ba2afda-2c42-4ac3-8ead-6982e384f1b3}'
PS C:\WINDOWS\system32> zfs mount zfs-test-tank
PS C:\WINDOWS\system32> F:
PS F:\> zfs mount zfs-test-tank/test2
PS F:\> cd test2
PS F:\test2> mkdir test3

    Directory: F:\test2

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        2022-03-27     10:01                test3

PS F:\test2> ls
PS F:\test2> cd ..
PS F:\> zfs umount zfs-test-tank/test2
zunmount(zfs-test-tank/test2,zfs-test-tank/test2) running
recreate mountpoint /zfs-test-tank/test2
zunmount(zfs-test-tank/test2,zfs-test-tank/test2) returns 0
PS F:\> cd test2
PS F:\test2> ls

    Directory: F:\test2

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        2022-03-27     10:01                test3

PS F:\test2> C:
PS C:\WINDOWS\system32> zpool export zfs-test-tank
zunmount(zfs-test-tank,F:\ ) running
zunmount(zfs-test-tank,F:\ ) returns 0
PS C:\WINDOWS\system32>

lundman commented 2 years ago

Thanks, good issue. You can run zfs mount to list where things are but what you are saying is that the "reparse point" mounting has issues, I'll take a look. Especially amusing the new directory sticks around after unmount

lundman commented 2 years ago

I re-wrote the reparse work, so maybe it have a chance now:

https://www.lundman.net/OpenZFSOnWindows-debug-2.1.99-984-gb95b51b57-dirty.exe

openzfsonwindows / openzfs