-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Broken VSS after installing #406
Comments
Might be a dup of https://github.com/openzfsonwindows/ZFSin/issues/354. @marcal commented 2 weeks ago there:
@SomebodyOdd, might be worth checking? |
|
OK it says
|
Interesting to note that if I change mimic to say
Wonder if we need to change the default back to always say |
Fair enough! Judging by the amount of similar effort put into WinBTRFS, eg. maharmstone/btrfs#681, now I think it's very much worth to mimic NTFS until OpenZFS driver gets bullet-proof. The workarounds (needed to turn off the mimicking and stay a distinct FS) could be added later (or by additional contributors if the project gets some ones). |
I still don't get why VSS even wants to talk with ZFS, even when I report as ZFS. I don't claim to support it, so it is frustrating it even tries. |
Dokany seems to not break VSS (at least, when I last dealt with it, I cannot try it for now) while dealing with being a filesystem itself, maybe something can be found in source code regarding that? Sorry for not providing further logs and diagnostics, I'm not near my windows machine and won't be for some time. |
I assume winbtrfs also doesnt break |
Hello, vssadmin 1.1 - Outil ligne de commande d’administration du service de cliché instantané de volume Nom du rédacteur : 'Task Scheduler Writer' Nom du rédacteur : 'VSS Metadata Store Writer' Nom du rédacteur : 'Performance Counters Writer' Nom du rédacteur : 'System Writer' Nom du rédacteur : 'ASR Writer' Nom du rédacteur : 'BITS Writer' Nom du rédacteur : 'Shadow Copy Optimization Writer' Nom du rédacteur : 'WMI Writer' Nom du rédacteur : 'MSSearch Service Writer' Nom du rédacteur : 'Registry Writer' Nom du rédacteur : 'COM+ REGDB Writer' vssadmin 1.1 - Outil ligne de commande d’administration du service de cliché instantané de volume Nom du rédacteur : 'Task Scheduler Writer' Nom du rédacteur : 'VSS Metadata Store Writer' Nom du rédacteur : 'Performance Counters Writer' Nom du rédacteur : 'System Writer' Nom du rédacteur : 'ASR Writer' Nom du rédacteur : 'BITS Writer' Nom du rédacteur : 'Shadow Copy Optimization Writer' Nom du rédacteur : 'WMI Writer' Nom du rédacteur : 'MSSearch Service Writer' Nom du rédacteur : 'Registry Writer' Nom du rédacteur : 'COM+ REGDB Writer' |
it is a great mystery, sometimes all pass, sometimes fail - I suspect it isnt the running at the time, but rather something that happens much earlier. |
Matching entry in event log:
As expected. However, with an addition...
So apparently the problem isn't with creating shadows, strictly speaking. It happens later, on trying to access the shadow volume:
Even FileSpy fails to attach to it.
Interesting... with 50GB already allocated of which none used, unbounded maximum and a 2TB disk, it thinks it's running out of space.
|
Woah ok that is interesting - didn't know any of these commands, so you are ahead of me. But a couple of things do sound interesting, like
|
Poking around in these sources: It could be suggesting
Both of those could be true, no idea what the latter is. So errors from:
Sadly, it seems VSS_E_PROVIDER_VETO is the generic error as well. |
On trying to create a normal snapshot with vssadmin, with an invalid noautorecover one from earlier already present:
And then hundreds of these
Until suddenly
And then it repeats over and over again. It only stops when the noautorecover snapshot gets deleted for alleged space problems.
It seems all attempts to mount the shadow volume, even if everything involved is NTFS, fail while the driver is present. There's also a bunch of these
though I'm not sure of their significance, other than maybe implying that anything that treats it as a volume breaks. Attaching the wall of text as a file. |
In the VSS sources, one of the checks it does is, calling
and
where all of those has to be set. OpenZFS I reply with deliberately NOT including Then asks for Then asks ioctl Then it writes to As for |
Not sure how chatgpt went from VSS_VOLATTR_SUPPORTED to listing those attributes, it seems to be just 1 in the code base. |
From a (admittedly blind) search for what exactly https://devblogs.microsoft.com/oldnewthing/20201021-00/?p=104387
https://devblogs.microsoft.com/oldnewthing/20201022-00/?p=104391
Does such a request even make sense here? Does the volume have a unique physical disk? It certainly does not in the case of RAID-Z. The fact that it breaks when there are no volumes makes me suspect that VSS is asking the question to something that isn't meant to answer it. Could the |
We do have a IOCTL_STORAGE_GET_DEVICE_NUMBER handle, and we always return 0 - but it is hard to imagine why that would be the issue when VSS also fails when nothing is mounted. You can't call IOCTL_STORAGE_GET_DEVICE_NUMBER without first opening the mounted volume to issue it to? But I suppose also, that could be an interesting debugging session, comment out more and more of the OpenZFS driver, until VSS works again. |
this VSS issue only appear after 2.2.6-rc*, I tested 2.2.3 in a VM at lease |
Hmm so latest 2.2.3 and earliest 2.2.6 would be interesting to compare. It could be INF change, or that we added IRP_* to reply which didn't used to reply. |
after some painful compile and test , I can confirm this issue cause by 8c07c15 |
Awesome thanks. That is where got mounting working, so it is a rather large commit, but it does narrow down what to look at. |
I got chkdsk to work after 66a4881 |
System information
Describe the problem you're observing
Just installing OpenZFS 2.2.6 RC7 breaks VSS, even if there are no pools present on system.
Most notably - it manifests as errors during chkdsk runs.
Describe how to reproduce the problem
chkdsk /scan
on NTFS volume (or any operation that tries to create a shadow copy, really)Include any warning/errors/backtraces from the system logs
This results in errors related to shadow copy provider from chkdsk command. Application event log contains VSS event 12289 with
hr = 0x80070001, Incorrect function
This error is consistent no matter what tries to create a shadow copy - I was able to reproduce it using chkdsk, built-in System Restore feature and Macrium Reflect trial version.
The text was updated successfully, but these errors were encountered: