glennv

nope ☺️ Guess its related to using an smbios of an as of yet not existing MacPro hahaha. tried with 8/16/32G mem. no difference. so far seems cosmetic (i hope) 🙏

Tnx Leoyzen, You saved me from going mad after a few days struggle to get upgrades (either from mojave or from latest catalina beta win Vega 56 card) to catalina final working. Whatever i tried , it never worked. either bootloops or freezes. Was super confused as all worked fine for every beta until the final, which broke. Was something in my EFI but endless tries did not managed to find it. Did find the bootlooper (fixed by MCEReporterDisabler.kext) but ran into other crap. By using your catalina.clover.qcow as a base and overwriting my own, adding MCEReporterDisabler.kext, Lilu and CPUfriend to kexts/Other directory (to keep /Library/Extensions clean) it finaly went thru on a copy of my main Davinci Resolve render node. All working fine incl acceleration as pre upgrade. Was using iMacPro1.1 before but the new Macpro7.1 seems to also work great post upgrade. Not sure if there is any sideeffects of the funny message about memory banks. Renders tests all good and no difference so guess we can ignore it, but if you find anything please let us know. p.s. Am using physical 10G cards so have not looked into virtio that seems to have some succes now, but maybe in the future (as i dont like that it needs post start hotplug apparently). I used physical hardware basically because virtual network cards on OSX sucked bigtime sofar so if that situation has changed it would be a very interesting development.

run it with specifying size. Using a zero never worked for me. So for example : diskutil apfs resizeContainer disk0s2 48G rem: if you get an error complaining about partition map too small, run "diskutil repairDisk /dev/disk0" and then retry the resize. You typicaly get this error if you use the diskutil gui version to resize the container. Running this command before fixes that.

Tnx for your fast feedback.

Something else i do wonder though with using ZFS. How about trim for ssds ? I have several ZFS ssd pools and the normal trim command i would run against my btrfs pool(s) does not work anymore for zfs. Is it part of ZFS itself somehow ? Or am i missing something ? --- # fstrim -v /mnt/disks/virtuals fstrim: /mnt/disks/virtuals: the discard operation is not supported

Personaly i am happy with the main array as it is. But have been bitten now about 3 times with corrupt btrfs cache pool. I use a large multi TB ssd (btrfs raid1) cache pool for speed and direct fast (via 10GB ether) access to video data . I keep projects that i am working on in the pool and once done trigger mover to move them to the (still fast 7200rmp) spindels (xfs). Back and forth with unbalance keeps it very workable. For my vm's i enjoy the snapshots feature of btrfs But 2 of these times i was hit it resulted in corrupt VM images that btrfs could not fix and the last one into complete pool corruption, that was not fixable by any of the btrfs methods i researched. Of course have good backups but it sucks having to rebuild everything and drops my sense of btrfs reliabilty to near zero (while i was bragging about btrfs to most of my friends untill then) At that time i did not know much if any about zfs. Started reading up on it, installed the plugin, moved most data i kept on the btrfs cache to ssd only zfs raid1 pools and they have been stellar since. Also zfs literay (in plain english rather then useless syslog messages) told me the main reason that i had issues with btrfs already in the first weeks , which was a wobbly connection to 2 of 8 ssds in a hotswap cage, but in contrast to btrfs it only reported it but kept fixing any issue continously and kept the pool healthy, where btrfs broke in same setup / same disks / same cables / same problems. I unplugged and replugged live ssd's to see which drive it was and all the time zfs kept smiling like nothing happend. There is just "zero" comparison or competition with btrfs . Specs or having a system runnig for years without issues are nice but real world behavior when there "are" issues and how you recover from them is what counts. The argument that btrfs has and zfs does not have recovery tools was mute in my case as none of the tools helped me at all other then to save some part of the data but not it fixing the pool, while zfs just fixed it for me while helping me also identify the problem. So i have become a complete convert from a btrfs advocate to a zfs fanboy. So a great option would be to be able to have zfs for cache only so get the best of both worlds. I can live without it for the main array as i see less benefits and more complications on implementing it there as already discussed. Nice pool features but still a fast and super reliable cache pool (with raidzx options as i did not even mention btrfs lack of anything (reliable) more then raid1/10)

Ah well, i just put the export and re-import commands in the go file and now its fine. But still wierd. Same for both of my unraid +zfs plugin boxes.

To not explode the post , i grepped on mountpoint as i guess that is what you need right ?. Its all good but after boot i have to redo it as described. The pools willl default be mounted at root level after boot. #zfs get all | grep mountpoint ZFS_BACKUPS_V1 mountpoint /mnt/disks/ZFS_BACKUPS_V1 default ZFS_BACKUPS_V1/DCP mountpoint /mnt/disks/ZFS_BACKUPS_V1/DCP default ZFS_BACKUPS_V1/FCS mountpoint /mnt/disks/ZFS_BACKUPS_V1/FCS default ZFS_BACKUPS_V1/NODE1 mountpoint /mnt/disks/ZFS_BACKUPS_V1/NODE1 default ZFS_BACKUPS_V1/TACH-SRV3 mountpoint /mnt/disks/ZFS_BACKUPS_V1/TACH-SRV3 default ZFS_BACKUPS_V1/W10 mountpoint /mnt/disks/ZFS_BACKUPS_V1/W10 default ZFS_BACKUPS_V1/appdata mountpoint /mnt/disks/ZFS_BACKUPS_V1/appdata default virtuals mountpoint /mnt/disks/virtuals default virtuals/DCP mountpoint /mnt/disks/virtuals/DCP default virtuals/FCS mountpoint /mnt/disks/virtuals/FCS default virtuals/NODE1 mountpoint /mnt/disks/virtuals/NODE1 default virtuals/appdata mountpoint /mnt/disks/virtuals/appdata default virtuals2 mountpoint /mnt/disks/virtuals2 default virtuals2/Mojave mountpoint /mnt/disks/virtuals2/Mojave default virtuals2/MojaveDev mountpoint /mnt/disks/virtuals2/MojaveDev default virtuals2/TACH-SRV3 mountpoint /mnt/disks/virtuals2/TACH-SRV3 default virtuals2/W10 mountpoint /mnt/disks/virtuals2/W10 default edit : in case you do need other stuff. Here from a single pool. # zfs get all virtuals NAME PROPERTY VALUE SOURCE virtuals type filesystem - virtuals creation Fri Sep 6 15:29 2019 - virtuals used 207G - virtuals available 243G - virtuals referenced 27K - virtuals compressratio 1.33x - virtuals mounted yes - virtuals quota none default virtuals reservation none default virtuals recordsize 128K default virtuals mountpoint /mnt/disks/virtuals default virtuals sharenfs off default virtuals checksum on default virtuals compression lz4 local virtuals atime off local virtuals devices on default virtuals exec on default virtuals setuid on default virtuals readonly off default virtuals zoned off default virtuals snapdir hidden default virtuals aclinherit restricted default virtuals createtxg 1 - virtuals canmount on default virtuals xattr on default virtuals copies 1 default virtuals version 5 - virtuals utf8only off - virtuals normalization none - virtuals casesensitivity sensitive - virtuals vscan off default virtuals nbmand off default virtuals sharesmb off default virtuals refquota none default virtuals refreservation none default virtuals guid 882676013499381096 - virtuals primarycache all default virtuals secondarycache all default virtuals usedbysnapshots 0B - virtuals usedbydataset 27K - virtuals usedbychildren 207G - virtuals usedbyrefreservation 0B - virtuals logbias latency default virtuals objsetid 54 - virtuals dedup off local virtuals mlslabel none default virtuals sync standard default virtuals dnodesize legacy default virtuals refcompressratio 1.00x - virtuals written 27K - virtuals logicalused 276G - virtuals logicalreferenced 13.5K - virtuals volmode default default virtuals filesystem_limit none default virtuals snapshot_limit none default virtuals filesystem_count none default virtuals snapshot_count none default virtuals snapdev hidden default virtuals acltype off default virtuals context none default virtuals fscontext none default virtuals defcontext none default virtuals rootcontext none default virtuals relatime off default virtuals redundant_metadata all default virtuals overlay off default virtuals encryption off default virtuals keylocation none default virtuals keyformat none default virtuals pbkdf2iters 0 default virtuals special_small_blocks 0 default

Love this plugin. One issue i have is that mountpoints seem to not be persistent over a boot. After the boot i have to do a zpool export <pool> and then an import -R <mountpoint> <pool>, to get the mountpoint correct again. zfs get mountpoint shows it correctly after the reimport. Anything i missed ?? Its shitty as my dockers/vm are on there so will fail after reboot untill manualy fixed.

Unraid rocks hard. So happy bday and yes, feel free to send me that coveted badge.

Great stuff man. Thanks for you efford in figuring this out for us.

+1 Absolutely vital i would say to be able to disable all these mitigations for non exposed servers or whatever. Couldnt care less for my server. I just need as much perf as the cpu can deliver. But hats of for LT for beeing on top of this. Respect.

+1 for integrated in Unraid. currently happy using cloudcommander but nothing beats integrated,

Thank you thank you thank you thank you !!!!!! All my latency issues on my OSX Sierra Render VM are gone like the wind. (had huge issues with midi controller devices and driven mouse/screen movements) Also in pure speed i noticed a few fps increase on some specific Davinci Resolve performance tests.

Yeah i realise looking at the logs but i prefer slow vs suddenly NOT working if you get my point. This sort of thing should never ever suddenly lead to the whole docker not working but rather just warn or at least the gui should work with then a warning to the user to correct any issues. Reminds me of my windows days before i moved to osx where at any day you could come in and find stuff not working due to a busted auto update. I hear its still the case with windows 10. My internet business line is so fat(500MBytes/s) i did not even notice it was slow as slow was still fast enough . Will switch endpoint at some time in the future the proper way as you suggested.

In case like me you dont want to or have no time to mess with a previously fine working config and roll back to the last working image , just use this as your repository adress in your docker settings : binhex/arch-delugevpn:1.3.15_14_gb8e5ebe82-1-14 the syntax is basicaly a colon plus the tag name of the image you want, which you can get from the docker repo website. That way youcan go to any version available. edit: not sure how it can be an endpoint issue suddenly as that would then also not work when i revert to an older version would it ? Will try it next week when i have more patience as happy with the previous version

Have the same problem . Stuck in some retry loop . How do i revert to an older docker image to get this working again edit: figured it out and reverted to previous image, which works fine.

You can get plex to work again by pointing it to /mnt/cache/appdata instead of /mnt/cache/appdata. Assuming you have appdata on cache. That is true for a few other dockers as wel like Sonar for example

64gb mainly for a huge memory hungry osx vm render node