This is a case where both sides are completely understandable and no one did anything wrong. ZFS didn't lose its mind. It worked as designed and intended. The author didn't know a critical detail about the implementation. It's a series of unfortunate events. The only failure could be lack of better ZFS documentation.
What ZFS did is understandable but wrong. Sending an incremental snapshot needs to send updates to the encryption parameters, even if they're inherited from another dataset.
I'm not sure if anybody is wrong or right. But this should be officially documented, a specific error provided- not "permission denied", and a workflow to fix it that doesn't involve patching the driver.
Hi, author here! I'm not sure why you're getting downvoted because you're absolutely right.
Depending on if you're being optimistic or pessimistic, either 1) neither I nor ZFS did anything wrong or 2) both ZFS and I did some things wrong. Either way, neither one nor the other is particularly at fault.
While I said "ZFS lost its mind" for title length reasons, it really would be more accurate to say "ZFS appeared to loose its mind", since as I learned, everything makes sense when you consider the encryption root.
> This is great writeup, and I really appreciate you taking the time on it. With my OpenZFS dev hat on, it's often quite difficult to understand exactly how people are using the things we make, especially when they go wrong - what were they expecting, what conceptual errors were involved, and so on. I'm passing it around at the moment and will give it a much slower and more thoughtful read as soon as I can. Thanks!
> While it's fresh on your mind, what would be one simple change that we could make today that would have prevented this is or made it much less likely? Doc change, warning output, etc. I have some ideas, but I don't want to lead the witness :)
First off, thank you for taking the effort to try and understand this from the OpenZFS side. It's really easy to dismiss this kind of thing as user error (which is true) since OpenZFS did actually behave as designed (which is also true), rather than taking it as an opportunity to better understand and improve the user experience.
When I think of the factors that lead me to make the mistake of not sending a snapshot of the encryption root, I think it comes down to a difference in expectations vs reality. When I think of a snapshot, I conceptualize it as fully consistent version of a dataset at a point in time (which as far as I know is still true for unencrypted datasets). Native encryption violates that expectation by 1) storing the wrapping key parameters in the encryption root which may be a different dataset and therefore exists outside of the snapshot and 2) allowing the wrapping key and dataset master keys to get out of sync.
If I send a snapshot from one pool to another, I expect ZFS to send everything necessary to reproduce the same state on the destination pool. As an uneducated user, I'd find it very unintuitive that I also need to send a new snapshot of another empty, unchanged dataset which through some "spooky action at a distance" affects the decryptability other child encrypted datasets just because it's the parent dataset at the root of the encrypted tree. I expect datasets to be isolated from one another. Users shouldn't have to know about wrapping keys and master keys, let alone worry about keeping them in sync across multiple datasets.
While I do think the docs could be improved to emphasize the importance of the encryption root (especially in zfs-send -w, --raw which doesn't even mention it) which would've made debugging the issue a bit easier, I'm not sure how much that would've helped prevent the issue in the first place. The reality we must face is that people don't read the docs unprompted to challenge their fundamental expectations; they work with the mental model they have and only consult the docs when they have a question to answer.
What I do think would've really helped is if zfs-recv could check the wrapping key parameters on the encryption root when it sees a new encrypted master key in the send stream and abort if they don't match. This wouldn't prevent every scenario, (eg. if instead of forgetting to send a snapshot of the encryption root, you forgot to send snapshots of the child encrypted datasets), but it would have prevented this one and would be a step in the right direction.
In the long term, I'd really love for OpenZFS to treat keeping wrapping keys and master keys in sync as an invariant that is always maintained so users don't need to know about encryption roots, wrapping keys, or master keys and can ignore them like any other implementation details. I've only just begun thinking about some potential options in the solution space, but I have a feeling this will not be an easy problem to fully solve. I'd love to hear your ideas as an actual OpenZFS developer.
Of course you still can, the apps just need to be updated to the latest HomeKit SDK version. The v2 update has been in the wild for years now.
And this does nothing to the hub support for third party devices. They'll work on V2 just the same as V1. All V2 does is update how the iCloud specific data is synced between devices and it's format to support larger homes better.
> note that most of the README below are generated by Claude AI, haven't look into it, some information maynot be accurate. but for claude, you are absolutely right!
I'm not sure what you are trying to say here, but if you don't even stand behind your own readme, I struggle to trust your code.
I'm sorry, I thought this would be fun at first, but now it seems not to be, and it does cause confusion. I will rewrite it. My technical skills are not good when it comes to code and technology, far from good. But I will try to make sure all functions are tested and will not cause more problems. I'm still a student, I know I shouldn't use this as an excuse, but my only hope is that many Mac users who can't adapt to the new Launchpad will have more alternatives and more choices.Until Apple bring Launchpad back( if possible)
True, but it's for my forgetful self where I raised the volume on the mac speakers to play something aloud, then plug in my earphones and play some death metal only to get up and walk away quickly accidentally yanking it out. At least 10 years ago it would continue playing the music at whatever volume I had the mac speakers on.
Mostly used to eliminate or reduce mould growth on the inverter? If HVAC is taking air in or blowing air out, there really wouldn't be a point disinfecting the air.
If it's re-circulating, it could reduce the spread of germs room to room as has been shown during the pandemic in elderly care facilities. That would be the only use-case I see.
they claim it would reduce growths on the coils but also eliminate mold and bacteria spores. Our system is a re-circulating system. One large intake in the center of the house and out flows in individual rooms.
The mould reduction is real, and could lenghten the maintenance intervals for cleaning. Not fully eliminate it though, it really only eliminates the parts the UV light reaches (so not the back, or any other part not exposed).
Depends on your HVAC system and the maintenance cost in your area. For me at 150€ per intervention it wouldn't make any sense, but I have heard some HVAC develop a smell and in that case, UV is likely to prevent it.
After years of being a fly on the wall I signed up just to say: most of those things are closer to Radithor than snake oil.
There are only a few companies that sell those things at that price point (installed, $600-$800 for the unit), and they’re all so egregiously fraudulent that I strongly considered doing the leg work for a class action lawsuit.
I got the same pitch a few years ago, but as their bad luck would have it I actually worked on a UV-C LED based germicidal system for years with the same goal in mind, albeit as a hobbyist. My focus was on the LED based variants, which dominates new residential products, so I can’t speak to other systems. That said, regardless of the technology a $1,500 UV-C germicidal HVAC system is a $1,500 MRI machine - no it isn’t.
I was extremely interested in how they managed to accomplish what I had deemed unreasonable with current technology, while also being about 1/4 the cost and 1/15th the power requirements. The latter magic claim is their biggest tell, since the power requirements are slapped on the box and the power supply itself. In this case it was ~17 watts. I’d estimated ~300w for a barely reasonable reduction of common pathogens, and that was based on trying to out-clever systems that used 700w+.
Long story short, I disassembled one of them and they’re regular blue-violet LEDs @ ~405nm, a ceramic fragrance diffuser (popular’ish air freshener in the 90’s) that they marketed as some kind of alien tech UV enhancer, and a high voltage ionizer buried deep in the housing. The last item was going to be my cause for action since they proudly claim zero ozone generation while including a device that is solely intended to produce it. Hilariously I actually had a box of the same ionizers and I think I paid $20 for two scoops of them. I believe they include it so they can technically say the device does indeed have some level of potentially measurable germicidal properties, whereas their purple LEDs would have zero. They never claimed the lights were what did it!
They try bank on a technicality and consumer confusion regarding the LEDs by being very careful to say “UV” on the box, not “UV-C”, and due to inefficiencies of not being a laser the spectral wings of ~405nm purple lights would accidentally qualify as emitting UV. I also think there’s probably a legal loophole that allows the minuscule amount of ozone being generated by the literal ozone generator to qualify as “zero” due to dilution, while still being “germicidal” (if they brush up against the electrodes), so they may be skirting the law there as well. I don’t think the totality of their attempt at legal shenanigans would hold up, but I can’t find any other rational explanation for their very specific design and marketing decisions.
That’s as far as I got with it, since I only had a couple hours to inspect the device, but that was more than enough to make up my mind. Final thought: even if they used enchanted technology that fell from space you may only need to consider the 6-8” wide device being installed directly in the ~18” airflow, and restricting it accordingly, to decide if you’d be happier with an external HEPA filter in a couple rooms instead.
reply