Hur bygger man en billig filserver med plats för +25 diskar utan att spräcka plånboken?

Du bör nog satsa på SAS HBAs men vilka diskar du kör är nog av mindre intresse, SATA-diskar går att köra på SAS-kontrollers.
Chassi är väl det svåraste att lösa misstänker jag. Ett gäng Hårddiskhyllor och en dator med externa SAS-HBA-anslutningar kanske? Om du nu inte ska köpa en färdig fillagringsserver av äldre karaktär.

Jag är ingen expert på området men 45-60 diskar är mycket mer än man brukar hantera med vanliga PC-prylar, så det är nog rätt stor risk för diverse strul om du försöker göra något hemmabygge.

6000$ låter som ett riktigt bra pris.

Om prestanda är irrelevant, vad hindrar dig från att hugga några gamla chassin med plats för 7+ diskar och köra ett enklare moderkort i varje, sata-pci kort om platserna på moderkortet inte räcker. släng upp varje maskin som en share på nätverket.
Jag antar att något här inte blir tillräckligt bra eftersom du frågar men jag vet inte vad det fallet på

Som OS så hade jag kikat på freenas. Enkelt att sätta upp och hantera samt gratis och har 100% stöd för ZFS. Linux (ubuntu) är inte fel heller men kolla på freenas, har för mig de bytt namn så de heter truenas nu, även gratisvarianten. unraid kan vara nått också har sett att det är många som använder det här inne men tror det kostar några hundringar.
Och SAS kontrollerkort är väl att rekommendera och om du ska använda ZFS så "måste" de vara IT-mode dvs ingen raid på dem utan bara kontroller för hdds. Annars fungerar inte ZFS som fullt ut som det är tänkt.

Ska det bara vara billigt för hemmabruk så är satadiskar det bästa. Ett tips där är att kolla på externa diskar som ibland är billigare för samma storlek som att köpa diskarna löst. Jag köpte själv 5 st 8 TB för samma pris som 4 st kostade annars genom att köpa externa diskar när det var rea.

Konsument 2.5" SATA-diskar som finns att köpa i 1-5TB klassen är alla idag SMR-diskar från alla tillverkare (skall du chucka 2.5" diskar från 1-5 TB USB-diskar så är det bara Seagate att välja på de har behållit SATA-anslutningen på sina diskar medans diskar från WD och Toshiba är istället inlödda USB anslutningar och diskkontrollerkortet USB/SATA-konverter)

- tänker man köra på ZFS är det ingen bra alternativ - men ser det inte förrän du behöver byta disk och kör resilvering och kan plötligt stå med ej räddningsbart havereras ZFS-filsystem.

Skall man ha CMR-diskar i 2.5" format så är det dyra saker i 10 och 15 KRPM-klassen med dual-SAS anslutningar, kräver både 5 och 12 Volt för att fungera och små storlekar (1.2 TB är en _stor_ 2.5" disk i dessa sammanhang) - men å andra sidan är driftsäkerheten och dataflöde vid sökning, läsning och skrivning i helt annan klass än vanliga SATA-diskar och utan begränsning i hur mycket som kan skrivas.

BTRFS via madadm-RAID kan hantera SMR-diskar bättre men kan behöva skicka till kärna att stoppa och starta synkningen i perioder så diskar får vara ifred i 20 minuter period per 1-2 timmar synktid (man får prova sig fram). Det går betydligt fortare än om synkningen trycker på konstant och PMR-arean är smockfull till sista blocket hela tiden och man minimera risken för utsparkad disk ur RAID:en för att responstiden är över 8 sekunder för någon av diskarna går över gränsen i responstid (ibland kan det behöva skriva om många SMR-block innan det kan ta bort tillräckligt med sektorer i sin interna PMR-area i tillräcklig storlek för att släppa in ny data utifrån och då kan det bli långa responstider[1] - dvs. situationen är som att man har 99,99% fylld filsystem och så fort en sektor raderas så fylls den med en ny och sedan tycker att den är långsam i respons...).

Kör man native BTRFS-RAID så går det köra motsvarande kommandon (pausa 'balance') för att starta och stoppa diskintensiv synkning men det är inte så känsligt som många andra RAID-upplägg i och med att det skriver i hela 1GB-shunk sekventiellt.

om man siktar på chucka 3.5" diskar så får man sikta på storlekar 10TB och större som är CMR medans storlekarna under kan vara SMR.

det värsta man kan lägga på en SMR-disk är filsystemet NTFS då den sitter och modifierar samma 32 MB-strip sektorvis när den uppdaterar $MFT - disken inser att den kan inte göra read-modify-write-sekvens var gång så alla dessa småsektormodifieringar trycks ned i PMR-area på SMR-disken som en skrivkö av sektorer och hoppas på att det blir lugnt senare och sortera upp sektorerna på PMR-arean - detta gäller framförallt när det hanterar väldigt många småfiler (som c:/programfiles och programfiles(86), windows mfl. med hårda och mjuka länkar i hundratusental) och detta är att tänka på om man skall göra iSCSI-enheter som man sedan exporterar och klienten lägger NTFS-filsystemet på ISCSI-drivern - där kanske inte SMR-disk är bästa alternativet för sin DAS/SAN-lösning.

[1] SMR-diskar kan inte städa och tömma sin PRM-area och skriva och läsa filer parallellt (brist på RAM-minne) - det måste ha minst 2 sekunder icke-access för att påbörja processen och avbryts och skrotar pågående sessionen omedelbart om datorn börja läsa och skiva på disken igen och är det aldrig avbrott i dataflödet mot disken (som vid synkning av RAID) så kommer PMR-arean aldrig få chansen att tömmas och när den är smockfull så börja disken stjäla tid för nödstädning för att inte helt stalla och det blir då utifrån sett som disken inte svarar under en viss tid och beroende hur spritt data är i PMR-arean och hur många SMR-block som måste läsas in modifieras och skrivas tillbaka innan blocken i PMR-arean kan frigöras så kan tiden blir ganska lång och olika RAID-system hinner sparkar ut diskarna. - problemet är inte särskilt olik som man upplever på konsument SSD/NVMe med SLC-cache - det går jättefort innan SLC-cachen är full, därefter hemskt låg fart där hårddiskar kan köra piruetter runt SSD/NVMe i avseende kontinuerlig skrivhastighet...

kom upp ett sådant moderkort på nyheter här på swec med 32st sata portar.

Härligt inlägg, bra jobbat!