RMS-200 SLOG inside VM benchmarks

The host:
i3-4160
16 GB DDR3
zpool: (fuck formatting!)
NAME STATE READ WRITE CKSUM
storage ONLINE 0 0 0
ata-WDC_WD4003FRYZ-01F0DB0_V1HXXXXX
ata-WDC_WD4003FRYZ-01F0DB0_V1JXXXXX
logs
nvme-RMS-200_00XXXXXX
cache
ata-INTEL_SSDSC2CT120A3_CVMP231104XXXXXGN

The results with 7 VM’s running with way too little memory allocated:


Only 1 VM running



“ZFS 2.0.0 final” install on Proxmox 6.x

####OBSOLETE AS OF MARCH 2ND 2021####
####PROXMOX NOW CONTAINS ZFS 2.0.3###


If the following guide gives you any trouble, find me on Discord and we can have a chat about it, possibly fixing your issue: https://discord.gg/H9uYucQ

Abit of an update to my previous post that installed the release candidate versions of ZFS2. This guide is for the final 2.0.0

ZFS2 is not officially supported by Proxmox at current time, but can be installed using this guide. Official ZFS 2 support will arrive in Proxmox 6.4

If you use “systemd”emon, you are cursed and this may not work for you!

This guide can also be used for Debian 10.5+ by replacing the pve-headers package with:

linux-headers-$(uname -r)

Commands to enter:

apt-get update

apt-get upgrade

apt-get dist-upgrade

apt-get install build-essential autoconf automake libtool gawk alien fakeroot dkms libblkid-dev uuid-dev libudev-dev libssl-dev zlib1g-dev libaio-dev libattr1-dev libelf-dev pve-headers python3 python3-dev python3-setuptools python3-cffi libffi-dev git

git clone https://github.com/zfsonlinux/zfs

cd zfs

git checkout zfs-2.0.0

sh autogen.sh

./configure

make deb

apt-get remove zfsutils-linux

rm kmod-zfs-devel_2.0.0-1_amd64.deb

dpkg -i *.deb

apt-get install zfsutils-linux

reboot

A word of Caution. When updating Debian or Proxmox after installing this you might have to run the above again if kernel versions change or ZFS packages are updated.

Revisiting PCR.

I previously posted links to articles questioning the RT-PCR test. The socalled “corman-drosten” report which has been questioned by “link

Here is what a Danish Doctor has to say about that paper and withdrawal request:

I forhold til kritikken som jeg tidligere har postet af RT-PCR testen er der kommet et svar fra et par læger. De har følgende kritikpunkter og meninger.: (skrevet af Morten Krogh Herlin)

Credentials: https://pure.au.dk/…/morten-krogh-herlin(22d9393f-f9c2…

Dette er en kopi fra en “privat gruppe”eg skal gøre mit bedste (det bliver lidt langt). Der er nok at tage fat på, og jeg kan ikke gennemgå det hele (rapporten er 29 sider).

Der er passager, som vedrører tekniske detaljer i analysesetup (temperatur, primerkoncentration), som du må spørge en molekylærbiolog om – det er uden for vores kompetencer 📷

Først og fremmest skal man forstå den kritiske artikel og den artikel der kritiseres i sin rette kontekst.Artiklen der bliver kritiseret er denne: https://www.ncbi.nlm.nih.gov/…/pdf/eurosurv-25-3-5.pdf…

Det er en artikel forfattet af en række anerkendte forskere fra flere europæiske lande og publiceret i Eurosurveillance (ECDC’s officielle videnskabelige tidsskrift) i januar måned 2020.
Hovedforfatterne er virologer fra et universitetslaboratorium i Berlin.

Artiklen udkommer på et tidspunkt, hvor smitten endnu ikke er nået til Europa, men hvor man skulle forberede europæiske laboratorier på den smitte, som man med god grund frygtede ville komme hertil. Derfor præsenterer de et design og workflow til at etablere testen i laboratorierne på et tidspunkt, hvor virus endnu ikke er til rådighed for laboratorierne.

Artiklen er ikke “grundlaget for selve PCR-testen” som nogle fejlagtigt gengiver den som. Men det var en konkret anbefaling i forhold til etablering af test i en tid, hvor virus endnu ikke var nået hertil.At man anvender RT-PCR test til detektion af SARS-CoV-2 er ikke spor odiøst.

Det var næsten givet på forhånd, at det var denne metode, man ville tage i brug, da RT-PCR de seneste to årtier har været den foretrukne metode til diagnostik af virusinfektioner overalt i verden. Tjek blot analysefortegnelse hos SSI for detektion af influenza, HIV, adenovirus, norovirus osv. osv. Alle disse påvises med RT-PCR.

Pudsigt nok har der aldrig før været så voldsom kritik af RT-PCR som metode. Jeg tror det er fordi vi står i en epidemi, som forståeligt nok giver anledning til frustrationer, politisk uenighed og på den baggrund også opstand og kritik mod diverse sundhedsvidenskabelige aspekter, fx testmetoden. Det er derfor at spørgsmål som disse egner sig bedst til videnskabelig diskussion.

Kritikerne af artiklen kommer med en række kritikpunkter. Det er dels kritikpunkter af selve artiklen. Kan nogle af disse være berettiget? Ja, det kan de meget vel være, da det er meget svært at udarbejde det “perfekte studie” i en tid, hvor virus endnu ikke er her og man forbereder sig på epidemien. Metoden på det tidspunkt var derfor af gode grunde ikke særlig grundigt valideret (det er den så i den grad blevet efterfølgende. Fx er ca. hver syvende prøve med virus blevet helgenomsekventeret og i tilfælde af at der skulle være særlige problemer med testen, ville det afsløre sig i disse sekventeringer)

Jeg tager et par af kritikpunkterne nedenfor.

Men de går længere end de konkrete kritikpunkter og bruger deres kritik af artiklen, som springbræt for en generel kritik af RT-PCR som diagnostisk metode (“which has led to worldwide misdiagnosis of infections attributed to SARS-CoV-2” og i konklusionen “which render the SARS-CoV-2 PCR test useless.” og “unsuitable as a specific diagnostic tool to identify the SARS-CoV-2 virus”), og det er her hvor de efter min mening går galt i byen.

Det har de nemlig slet ikke dokumentation for at postulere og det ville i så fald også være en kritik af to årtiers brug af metoden til nær sagt alle virusinfektioner. Hvis man skal tage det som en generel kritik af RT-PCR, så er de nødt til at komme med noget mere så at sige.Tag fx titlen på artiklen: External peer review of the RTPCR test to detect SARS-CoV-2.

De har ikke skrevet et external peer review af RT PCR testen.

De har skrevet en kritik af en artikel, der blev referencedokument for etablering af test i starten af epidemien. Det er noget andet i mine øjne.I øvrigt så er hele begrebet RT-PCR testen et bredere begreb end blot denne ene artikel og omfatter mange forskellige test-kits som kan variere laboratorier i mellem. Fx er der danske laboratorier, der anvender primers mod ORF1 genet i SARS-CoV-2 virus.

Det er slet ikke omfattet af det test-design, som præsenteres i den kritiserede artikel.Og endeligt, så præsenteres kritikken sammen med en betydelig politisk indignation. “We are confronted with stringent lockdowns which have destroyed many people’s lives and livelihoods, limited access to education and these imposed restrictions by governments around the world are a direct attack on people’s basic rights and their personal freedoms, resulting in collateral damage for entire economies on a global scale.”

Det skal selvfølgelig stå dem frit for at mene det, men det er meget usædvanligt at videnskabsfolk formulerer sig og argumenterer på den måde i en videnskabelig diskussion. Kan derfor ikke lade være med tænke at deres kritik ikke blot er udtryk for bekymringen omkring den videnskabelige kvalitet af RT-PCR testen, men også bunder i en mere politisk skepsis omkring hele epidemien (mere om dette til sidst).

2/2

Til (nogle af) kritikpunkterne:

3. Virus kan ikke skelne ml. hele viruspartikler og virus RNA. Sandt, da testen bygger på påvisning af arvemateriale ligesom RT-PCR diagnostik af alle andre virusinfektioner. Men de har ikke dokumentation for at det er et reelt problem og at alle påviste smittetilfælde i så fald skulle være falsk positive – det forestiller de sig bare at det er.

6. PCR produktet er ikke valideret. Jeg forstår ikke relevansen i dette, når en række positive prøver ( = amplificeret PCR produkt) efterfølgende er genomsekventeret med påvisning af hele sekvensen fra SARS-CoV-

2.7. Fravær af positiv kontrol. Igen, artiklen var en forberedelse til en epidemi på vej og man havde derfor ikke virus RNA. Testen designer de med baggrund i referencegenomet fra Wuhan, som kinesiske myndigheder offentliggjorde https://www.ncbi.nlm.nih.gov/nuccore/1798174254. Alle RT-PCR kørsler kører i dag med positiv kontrol, som man i øvrigt altid gør.

9. Manglende/utilstrækkelig peer-review. Jeg kan være enig i, at det kan være svært med grundig peer-review på så kort tid. Jeg kan ikke vide hvad redaktionen ved Eurosurveillance har tænkt på daværende tidspunkt. Måske at det var strengt nødvendig med hurtig publikation, så laboratorierne kunne komme i gang med deres forberedelser.I øvrigt har kritikernes artikel ikke selv været igennem peer-review og meget af den information forfatterne i øvrigt deler på twitter er heller ikke peer-reviewet. Så det er tilsyneladende ikke altid afgørende for kritikerne at dette krav er opfyldt.

Der er i øvrigt flere eksempler på forhastet peer review under epidemien, fx Didier Raoults første rapporter om hydroxychloroqin som skabte en stor hype omkring dets påståede effekt.Det er vigtigt at tidsskrifterne er åbne herom, hvis de finder det nødvendigt speede op.(I øvrigt fejlciterer de en undersøgelse omkring at 97% af alle prøver, når man anvender CT cut-off >35 er falsk positive. De glemmer forskellen på CT for den enkelte prøve og så det CT cut-off, hvor man kan konkludere at testen er negativ.https://academic.oup.com/…/10.1093/cid/ciaa1491/5912603mere herom i dette svar: https://www.facebook.com/groups/1319342428265022/permalink/1544469102419019)Til sidst kan vi også lige vende forfattergruppen. I alt har 15 af 21 forfattere bag kritikken blot bidraget med at godkende analyser og artiklen. Det er ikke nok bidrag til at opfylde Vancouver kriterierne for videnskabelige forfatterskaber. Jeg kan ikke vide hvad deres baggrund er for at være med på artiklen andet end at de måske deler det kritiske syn på testen/pandemien.Blandt forfatterne er en del velkendte navne, som ofte går igen i den kritiske debat vedr. pandemien. Fx Thomas Binder, som er hjertespecialist. Jeg har svært ved at se hvilken forudsætning han skulle have for at kloge sig i PCR?Men man kan ikke være i tvivl om at han er kritisk omkring hele pandemien (ja han fornægter tilsyneladende dens eksistens). Vedhæftet nedenfor er et hans nylige tweets. Det er svært at tage en kritik af en videnskabelig artikel særligt alvorligt, når en af forfatterne bag kritikken selv sætter barren så lavt.Et andet navn er Michael Yeadon. Han har blandt andet tidligere udtalt udokumenterede påstande om at epidemien skulle være ovre i England og at vaccinen skulle forårsage infertilitet. I så fald skulle han både være epidemiolog, immunolog og nu molekylærgenetiker, hvis han skulle have en særlig ekspertviden som baggrund for sine udtalelser.Hovedforfatteren Pieter Borger er molekylærgenetiker og har relevant baggrund for at udtale sig om PCR. Men på sin twitter er hans særdeles aktiv med diverse kritiske posts om epidemien generelt.Jeg kan ikke lade være med at tænke om deres kritik i nogen grad må være politisk motiveret. Bevares, de må selvfølgelig mene hvad de vil, men det bliver ofte forplumret, når det blandes sammen med videnskabelige spørgsmål. Og her er det særligt vigtigt, som du selv fint påpeger, at have øje for confirmation bias.Og generelt tænker jeg det er usandsynligt en enkelt forfattergruppe med vidt forskellige fagområder, skulle besidde et særlig kendskab til PCR testen, som resten af den etablerede videnskab ikke har.Mvh. Morten, læge



Windows users probably do not utilize their hardware effeciently.

Let’s take a fictional set of hardware specs:

-Ryzen 7 3700x
-32-64GB of Ram
-2x4TB HDD’s
-1-2 512GB NVMe’s
-1-2 SATA SSD’s
-Some GPU

Most users put their Windows 10 on the NVMe’s either in raid1 or using them as two individual devices.
The SATA drives are used to store stuff, maybe the mayority of the steam library and normal documents. They might be Raid1

The memory above 16GB is mostly unutilized for the regular consumer without the need for video editing.

Here are a few fun facts about SSD’s:
-They are not meant for long term storage.
They lose data over time. Essentially the cells are written to once and given a certain electrical charge. This charge is never refreshed unless the cell is overwritten and diminishes over time. HDD’s do not have this problem. This issue is called “de-trapping” and also applies to USB sticks
SSD’s fail at the same time if run in RAID1. Both of them will reach their max TBWD at the same time and fail simultaneously, probably within a single week. The HDD’s do not have this problem.

So, what can we do with this information?
Well, we have memory, we have SSD’s and we have HDD’s.

What would AngryAdmin do?
He would install proxmox on two USB drives and mirror them with ZFS.
Configure a mirrored ZFS pool of the two 4TB HDD’s
Attach whatever SSD’s are avail to this pool of HDD’s as L2ARC persistent cache.
Install windows 10 as a virtual machine in proxmox, passthrough a few USB controllers and the GPU. Give theVM 24GB ram if total mem is 64GB, 16GB if total mem is 32GB. ZFS will use the rest as read cache(ARC) and write cache(ZIL)

Windows, Steam and important data is now stored on a pool consisting of one mirrored vdev backed by whatever SSD’s were present before. These SSD’s are striped in what could resemble RAID0 yielding twice the read performance.

Imagine having two NVM’es backing these 4TB disks.. The data you use most often will be cached on the NVMe and read at twice the speed of a single set of RAID1 NVMe. After windows and important stuff is cached, set options zfs mfuonly=1

Moreover, if the NVMe break, which they will eventually, the data is not lost, it is still stored on the two HDD’s

You now fully utilize the space of your NVMe’s. You speed up the entire system by having the ARC present data to your VM’s when needed. Of course ARC is cleared when you reboot, but persistent L2ARC is not.

You are now utilizing both your memory and your nvme’s and get 98-99% bare metal performance.

If you feel like it, add another GPU, install a 2nd windows, attach a 2nd keyboard and mouse and last but not least, another monitor to the 2nd GPU. have a friend over and play games on the same PC 2 people.

Regular users waste 16GB ram if having 32GB total. They waste SSD capacity by mirroring two drives. This solves that 🙂

My storage system currently looks like this:
6x2TB disks each mirrored to form 3 sets of mirrors. These 3 mirrors are striped “(Raid10) but not really raid10” 2x240GB SSD’s are attached to this pool of 6TB data capacity as 480GB speedy L2ARC cache.

A second pool with a 12 year old 1TB and a relativly new 4TB disk. The first to be replaced soon. The pool will auto-expand to 4TB when I replace the 1TB disk. This pool holds temporary data that is not important but I also do not want the IOPS this data on “storage2” requires interfering with IOPS on “storage”



ZFS 2.0 install on Debian 10.5 /Proxmox 6.2

OBSOLETED, REPLACED BY: LINK

Notes: For Debian 10: it is not required to remove packages prior to install of 2.0 unless a previous version of ZFS was installed on the machine. Read the last command of this guide before continuing.

Note2: If you are using your proxmox host for GPU passthrough it is adviced to set options zfs l2arc_mfuonly = 1 to not fill the cache with all sorts of crap if you are doing backups. It will most likely trash your SSD unless it is enterprise grade SLC within a few weeks.

Note3: This does NOT work for a proxmox or debian install with a root zfs pool!!!!!!!!!

WARNING: NOT SAFE FOR PRODUCTION

Here are the commands to enter in order for persistent l2arc to work with proxmox (debian based)

apt-get update

apt-get upgrade

apt-get dist-upgrade

apt-get install build-essential autoconf automake libtool gawk alien fakeroot dkms libblkid-dev uuid-dev libudev-dev libssl-dev zlib1g-dev libaio-dev libattr1-dev libelf-dev pve-headers python3 python3-dev python3-setuptools python3-cffi libffi-dev git

git clone https://github.com/zfsonlinux/zfs

cd zfs

git checkout zfs-2.0.0-rc6

sh autogen.sh

./configure

make deb

apt-get remove zfs zfs-dkms libzfs2 libzpool2 libnvpair1linux libzfs2linux libzpool2linux libuutil1linux

dpkg -i zfs_2.0.0-0_amd64.deb zfs-dkms_2.0.0-0_amd64.deb libnvpair3_2.0.0-0_amd64.deb libzfs4_2.0.0-0_amd64.deb libzpool4_2.0.0-0_amd64.deb libuutil3_2.0.0-0_amd64.deb zfs-test_2.0.0-0_amd64.deb zfs-dracut_2.0.0-0_amd64.deb zfs-initramfs_2.0.0-0_amd64.deb python3-pyzfs_2.0.0-0_amd64.deb

apt-get install zfsutils-linux

Last command removes some of the 2.0 installed packages but without this the pool wont mount on reboot. It does not limit the functionality of ZFS.
Read this for reason: https://github.com/openzfs/zfs/issues/10941

PCR notes. Temporary document. Expires: Yr 2422

SSI I DK bruger 38 cykler til at tjekke om en person er positiv eller negativ via PCR test. Dokumentation for SSI’s metode dokumenteret af SSI selv nedenstående.

PCR chance for positiv resultat stiger eksponentielt ved mere end 25 cykler.
Problematikken forklares i denne video: https://youtu.be/S_1Z8cSXI-Q

I Portugal er der afsagt dom om at PCR testen ikke er reliable til at teste for covid:

It’s here the ruling cites a study conducted by “some of the leading European and world specialists in this material” published by the Oxford Academic at the end of September.

“At a cycle threshold (ct) of 25, about 70% of samples remain positive in cell culture (i.e. were infected): in a ct of 30, 20% of samples remained positive; in a ct of 35, 3% of samples remained positive and in a ct above 35, no sample remained positive (infectious) in the culture”.

“This means that if a person has a positive PCR test at a threshold of cycles of 35 or higher (as happens in most laboratories in the USA and Europe), the chances of a person being infected is less than 3%. The probability of a person receiving a false positive is 97% or higher”.”

Kilde: https://www.portugalresident.com/judges-in-portugal-highlight-more-than-debatable-reliability-of-covid-tests/


Fauci fortæller hvordan 38 cykler er totalt ubrugeligt og giver false positive ved at replikerer døde celler.

Link til video med Fauci:
https://www.bitchute.com/video/X0Z3Whf2SopB/?fbclid=IwAR2x1d2-HNFbKKviTB9P4JGuoezN0fQiQKTv2J1pGvgT7O481-E6OPVcMBA

Kilde: Public Health England “Understanding cycle threshold (Ct) in SARS-CoV-2 RT-PCR (page 6 for important stuff)

Link: ARTICLE OPENS IN NEW WINDOW

Asrock x570 Phantom Gaming X review. It’s bad!

Bad board, Bad Support!

Well, I got the board, entered BIOS 1.70 and found SB_Temp sitting at 71C with the SB fan spinning at airplane turbine speeds… 6000 RPM. I pondered this, as the board should not be this warm while I was just browsing the BIOS for 5-10 minuttes. I decided to update the BIOS before venturing forth.

I update to 3.40 and enter the BIOS. SB fan still spinning at an incredible 6k RPM but the SB_temp was down… WAY DOWN… So much down that the actual reading is no longer visible in 3.40. I guess Asrock figured out their boards ran way too warm and essentially just attempted to hide this fact from users.

I attempted to install windows several times. It would continually reboot after “Configuring devices 86%” I was not able to get windows installed on the board.

I tested the ram with memtest86 coming up clean.

I placed extra fans on the SB, still rebootingI disabled every non-essential stuff in bios such as the wifi and BT. Still rebooting

Installed Linux, (proxmox) and installed windows in proxmox, no problem. GPU passthrough, No problem and that is how I am running the board now since installing Windows 10 clean is impossible.

I contacted Asrock tech support just to be ignored. It has been 3 weeks since I contacted them and nothing. I read on their forums from other users that Asrock simply stopped responding to tickets regarding SB_temp on their x570 Board….

I remember back in the early 00’s) where I would cringe in terror when seeing asrock boards in customer pc’s… I guess nothing has changed since then.

The most obvious issue I have with this is their attempt to hide the poor design from users by removing the temp-readout in bios and ignoring peoples support tickets…

Testing with “sensors” in Linux yields 71C and a whiney SB_Fan… 3.40 Did NOT fix it, just hide it.

I cannot recommend Asrock to anyone after this experience.