Hive: Difference between revisions

Latest revision as of 22:32, 13 January 2025

Hive is a VM on Melange that runs my TrueNAS storage.

Pools

Pool	Capacity	Type	Drives
mine	43 TB	raidz	8TB ssd x7
safe	5.2 TB	raidz	1 TB ssd x7

NOTE that there is an eighth 8TB drive matching the mine array in Bluto. Harvest it from there if one of the 7 dies.

Mine Drives

Unfortunately I opted for Samsung SSD 879 QVO drives. The ONLY 8TB SSD option available, for a long time now.

Problems:

They are not designed to survive lots of reads/writes.
Because they are so big, it is very hard to maintain them, with scrubs taking hours, and resilvers BARELY able to complete after days.

Yep, they suck. And now I am stuck with them. So I will keep getting new ones and returning the bad ones, until I can move to MVME drives on a new PCIe card.

Hardware

LSI 8-drive SAS board passed through proxmox to hive as "PCI Device":

7 1 TB Crucial SSDs

Plugged in to SATA 1, 2, 3 and U.2 1, 2, 3, 4. NOTE: to get U.2 drives to be recognized by Melange ASUS mobo required a BIOS change:

Bios > advanced > onboard devices config > U.2 mode (bottom) > SATA (NOT PCI-E)

Hive history

@@ Line 1: / Line 1: @@
-== TODO ==
+Hive is a VM on [[Melange]] that runs my [[TrueNAS]] storage.
-* move sassy and splat data to safe, remove them
-* continue migration until we have 7 slots free (16 - 7 safe - 2 grim)
-* add 7 new BIG ssds in new raidz array
-* rinse and repeat
-== Overview ==
-FreeNAS provides storage via Pools.  A pool is a bunch of raw drives gathered and managed as a set.  My pools are one of these:
-* single drive: no FreeNAS advantage other than health checks
-* raid1 pair: mirrored drives give normal write speeds, fast reads, single-fail redundancy, costs half of storage potential
-* raid0 pair: striped drives gives fast writes, normal reads, no redundancy, no storage cost
-* raid of multiple drives: FreeNAS optimization of read/write speed, redundancy, storage potential
-The three levels of raid are:
-* raidz: one drive is consumed just for parity (no data storage, ie you only get (n-1) storage total), and one drive can be lost without losing any data; fastest
-* raidz2: two drives for parity, two can be lost
-* raidz3: three drives for parity, three can be lost; slowest
 == Pools ==
-* Drives
 {| class="wikitable"
 ! Pool
@@ Line 28: / Line 9: @@
 ! Drives
 |-
-|sassy
+|mine
-|0.2 TB
+|43 TB
-| style="color:red" |single
+| style="color:green" |raidz
-|250GB ssd
+|8TB ssd x7
-|-
-|splat
-|3.6 TB
-| style="color:red" |raid0
-|1.82 TB hdd x2
-|-
-|mack
-|0.9 TB
-| style="color:red" |single
-|1 TB ssd
-|-
-|reservoir
-|2.7 TB
-| style="color:red" |single
-|2.73 TB hdd
-|-
-|grim
-|7.2 TB
-| style="color:red" |raid0
-|3.64 TB ssd x2
 |-
 |safe
-|6 TB
+|5.2 TB
 | style="color:green" |raidz
 |1 TB ssd x7
 |}
-== Datasets ==
+NOTE that there is an eighth 8TB drive matching the mine array in [[Bluto]].  Harvest it from there if one of the 7 dies.
-Every pool should have one dataset.  This is where we set the permissions, important for SAMBA access.
-Dataset settings:
- name #pool#-ds
- share type SMB
- user m
- group m
- ACL
-  who everyone@
-  type Allow
-  Perm type Basic
-  Perm Full control
-  Flags type Basic
-  Flags Inherit
-== Windows SMB Shares ==
-Share each dataset as a Samba share under:
+=== Mine Drives ===
-  Sharing > Windows Shares (SMB)
+Unfortunately I opted for Samsung SSD 879 QVO drives.  The ONLY 8TB SSD option available, for a long time now.
-Use the pool name for the share name.
+Problems:
+* They are not designed to survive lots of reads/writes.
+* Because they are so big, it is very hard to maintain them, with scrubs taking hours, and resilvers BARELY able to complete after days.
-Use the same ACL as for the dataset.
+Yep, they suck.  And now I am stuck with them.  So I will keep getting new ones and returning the bad ones, until I can move to MVME drives on a new PCIe card.
 == Hardware ==