Search results

TrueNAS drauf und los :) Entgegen meines Vorposters finde ich da Storage wichtiger und das bisschen Hypervisor kann auch TrueNAS. Man könnte auch keine grossen VM disks haben, weil die VMs selbst auf einen NFS share zugreifen und darum selber nur 50GB grosse VMs sind.

Another great explanation of that topic: https://forums.truenas.com/t/understanding-openzfs-capacity/2444 It even has a picture of a 7 wide RAIDZ2 with 128k. Not exactly your 8 wide, but pretty close: See the two X sectors? That is 8k padding for every single 128k stripe. It is similar with...

BTW, that calculator has an interesting note regarding the zfs list command you used: Maybe this is what screwed your tests? I honestly have no idea. Here is another, IMHO even better calculator. And if you scroll down all the way to the bottom, there is also explanations behind his math...

No, that is not an actual real-world result, considering how complicated free space reporting is in ZFS. That is: wer misst, misst Mist A real world test would be you setting up a 4 wide RAIDZ1 vdev with 1TB HDDs, create a 16k zvol with compression disabled, create a RAW image inside that zvol...

Verstehe nicht ganz deine Frage, noch dein Setup. Ich kann nur sagen, irgendeine Form von Disk, in Form einer Datei (zum Beispiel QCOW2 oder VDI) zu verwenden, und diese Datei/Disk dann auf ein NFS share zu legen, und dieser NFS share hat dann als Unterbau eine ZFS Dateisystem, was ein CoW...

Just for fun, we can do the math for your setup and what you should get with 128k. Let's look at a 132k write. First block is an incompressible 128k write. Second is also a 128k block but with only 4k data, the rest zeros. LZ4 can compress that down to a 4k block. Side note: This is one of the...

That question is an oversimplification ;) But most likely, it would rise of course. Since a lets say from 128k down to 100k compressed block can make use of wider stripes and easier fit the pool geometry, padding has less impact and so on. But nobody would use 128k for VMs. We have a saying in...

This is another big trap. I already explained that one: So no you are correct, of course won't see 96TByte for your 8 wide 18TB RAIDZ2. You will see 6*18=108TB as your rightfully said so far we agree. But if you create a zvol with the 16k defaults and then create a 1TB RAW VM disk, and fill...

That is correct, it is a oversimplification. But it does not get that much better if the data actually is compressible. What if a 16 block can be compressed to 4k? Then you have one padding & one data = 50% efficiency. Congrats you are now down to mirror efficiency. What if it can be...

That is not what it does. I unrealistically assumes that a 16k volblock is not compressable and because of that always a 16k write. It does not assume every write to be a tiny 4k block. It assumes a 4k sector size. I did not know about that. Do you have a link for that? Are you sure you are not...

Sorry, I misunderstood. In that case you can leave it. Sure. So Proxmox uses the good default of 16k volblocksize. That means that all your VMs ZFS raw disks, are offered 16k blocks. Now lets look how ZFS provides 16k blocks. You have RAIDZ1. The sector size of your SSDs is 4k. So each 16k...

Ich kenne mich null aus mit VMWare. Aber verstehe ich das richtig, dass du unter VMware eine disk ähnlich wie QEMU2 inter Proxmox erstellst und diese dann auf den NFS share von TrueNAS schiebst? Das kann fast nur in die Hose gehen. Ausser du verstehst zu 100% was du tust. CoW on Cow ist ganz...

I would recommend you to do - Backup the VMs - Backup your Proxmox settings - destroy, reinstall Proxmox - use mirrors! - reimport the VMs I would not use 5 drives as a RAIDZ1. With the default of 16k volblocksize you only get 66% and not your expected 80% storage efficiency. Not is not much...

Das ist definitiv seltsam uns sollte nicht sein. Von welchem Client aus ist das? Du hast aber hoffentlich nicht dedup am laufen? Klar, sync ausschalten macht auch nur sync writes schneller, weil du den client belügst. Lass besser die Finger davon, ausser du weisst, was du tust. Der IMHO...

Clickbait headline, but I think it is true :) Maybe others can chime in with their setups and why they need beefy hardware. Here is my PBS testimonial. Reading the documentation I was a little bit scared. Especially the storage part seemed brutal. Turns out it is not that bad and I...

Ist generell auch bei nicht so wichtigen Diensten eigentlich immer eine gute Sache. Hilft auch enorm beim troubleshooten. Der ganz grosse Vorteil von LXC ist die Nutzung von files anstelle von blockstorage. Das ist eine kompliziertes Thema und schwer zu erklären für newcomers und gleichzeitig...

Für den beschriebenen use case würde ich falls Lust auf ZFS da ist TrueNAS SCALE oder ansonsten openmediavault verwenden. UGOS und Synology traue ich nicht, deren Software scheint doch schon sehr Gebastel zu sein.

That does not solve the issues I have with blockstorage. A virtual disk will still be a fixed blocksize of 16k if using ZFS defaults. ZVOLs have a static volblocksize. Datasets are not blockstorage. They have an upper limit called record size. Files don't have a static record size, they are...

This might be an unpopular opinion, but I would say that best practice is to separate data from blockstorage. If you just use a 1TB VM disk, you get all the downsides of blockstorage, plus backing that up is painful. It is less painful with PBS, but still painful. On the other hand, running a...

Stimme deinem Bauchgefühl zu ;) Du schreibst von unerwarteten Neustarts, also Mehrzahl. Dein IPMI output hat aber nur ein Fehler. Hast du händisch geleert?