SSD + HDD combineren: btrfs, md of bcachefs?

[ktf]

Hallo,

Mijn fileserver is ondertussen 11 jaar oud en aan vervanging toe. Hij heeft jarenlang met 2 schijven in md raid1 + ext4 gedraaid, ik ben een paar jaar geleden gemigreerd naar btrfs raid 1. Voor de nieuwe server zit ik nog te denken wat ik wil doen. Het benaderen van de fileserver (via WebDAV) gaat namelijk naar mijn smaak soms te traag. Het openen van een map met flink wat bestanden kost soms een seconde of twee, en dat werkt niet fijn.

------

Voor de goede orde: Ik gebruik Ubuntu Server, en gebruik mijn RAID1 opstelling enkel en alleen om geen uitval te hebben in het geval een schijf kapot gaat, NIET als backup.

------

Mijn eerste ingeving: in plaats van 2 HDDs in btrfs RAID1 zet ik een HDD + SSD in dezelfde configuratie. Simpel en overzichtelijk. Ik lees hier dat er een patch is om inderdaad de snelheid van een SSD te benutten: https://www.phoronix.com/...x=RAID-1-10-Balance-Patch Hier lees ik echter dat er nog steeds over gebakkeleid wordt: https://stackoverflow.com...ich-device-gets-the-reads Blijkbaar heeft dit dus niet het gewenste effect.

Hier en daar lees ik dat bij gebruik van md er kan worden aangegeven welk apparaat sneller is, maar ik vond het juist zo fijn aan btrfs RAID1 dat er doormiddel van checksums kan worden bepaald welke kopie van een bestand de niet-corrupte is. In het verleden heb ik daar gedoe mee gehad. Dit heeft dus niet mijn voorkeur.

Andere twee oplossingen: in plaats van SSD+HDD toch 2xHDD maar meer geheugen zodat de kernel automatisch gaat cachen, of een kleine SSD als cache gebruiken via bcachefs. De eerste oplossing is voordeliger en minder werk, de tweede oplossing geeft waarschijnlijk meer performance. Van bcachefs vraag ik me dan weer af wat er gebeurd als de SSD ermee ophoudt.

Ik hoop op uw wijze raad Iemand hier met ervaringen, tips of oplossingen?

[ Voor 9% gewijzigd door ktf op 13-10-2020 15:54 ]

[Hero of Time]

Het klinkt enorm NOS, maar je hebt een vraag dat Opslagtechniek roept. Ik denk daarom dat je topic beter in dat forum tot z'n recht gaat komen ivm de daar aanwezige kennis.

NOS -> OT.

Heb je ook al naar ZFS gekeken om dat te gebruiken, al dan niet met een BSD variant zoals FreeNAS oid?

[Renault]

Alternatieve oplossing: de RAID1 vergeten, alleen een SSD toepassen en daarbij evt. een externe harddisk voor periodieke full backups, in combinatie met (evt. online, in de cloud) incremental backups?

Als je alleen een SSD toepast, heb je namelijk toch de volledige SSD snelheid.
En backups moet je sowieso al maken.

Met gebruik van een SSD ben je trouwens ook weer razendsnel live bij een failure als je backup oplossing snel genoeg is (ook op een SSD?). En dat is precies het doel van RAID1: snel weer online zijn.

[ Voor 24% gewijzigd door Renault op 13-10-2020 20:22 ]

[Ben(V)]

Btfrs Raid is nog steeds niet betrouwbaar, dus dat zou ik niet doen.
Als je niet perse snapshot nodig hebt zou ik gewoon Ext4 nemen en mdadm voor de Raid.

[jvanderneut]

Je kan in mdadm raid1 een device als write-mostly definiëren. Als je dat met je HDD doet zal voor leesacties bij voorkeur de SSD gebruikt worden. Of gewoon meer RAM kopen zodat er meer in de cache kan.

[ktf]

Renault schreef op dinsdag 13 oktober 2020 @ 20:20:
Met gebruik van een SSD ben je trouwens ook weer razendsnel live bij een failure als je backup oplossing snel genoeg is (ook op een SSD?). En dat is precies het doel van RAID1: snel weer online zijn.

Dit snap ik niet. Als de SSD ermee ophoudt, dan ben ik toch zeker een dag kwijt om een nieuwe te bestellen, backup terug te zetten etc. Hoezo ben ik dan razendsnel weer online? Bij RAID1 kan ik altijd nog degraded doorwerken.

Ben(V) schreef op dinsdag 13 oktober 2020 @ 23:24:
Btfrs Raid is nog steeds niet betrouwbaar, dus dat zou ik niet doen.

RAID5/6 weet ik, maar waarom zou RAID1 niet betrouwbaar zijn bij btrfs? Ik heb juist problemen gehad met md raid1, omdat een van de schijven een rotte kopie had van een aantal bestanden, en md maar niet kon kiezen welke kopie de juiste was. Dat risico heb ik bij btrfs niet. En inderdaad, ik gebruik de snapshot functie zeer uitgebreid, dus eigenlijk is ext4 geen optie.

jvanderneut schreef op woensdag 14 oktober 2020 @ 00:44:
Je kan in mdadm raid1 een device als write-mostly definiëren.

md raid gebruik ik liever niet vanwege problemen in het recente verleden.

Edit:

Hero of Time schreef op dinsdag 13 oktober 2020 @ 20:12:
Heb je ook al naar ZFS gekeken om dat te gebruiken, al dan niet met een BSD variant zoals FreeNAS oid?

Nee, eerlijk gezegd niet. Ik wil graag Ubuntu server blijven behouden (dan kan ik de configuratie overzetten), BSD is voor mij onontgonnen terrein. Verder heb ik hier en daar gehoord dat ZFS op linux nog steeds niet geweldig werkt? Ik heb me er nog niet echt in verdiept. Misschien toch maar doen

[ Voor 17% gewijzigd door ktf op 14-10-2020 07:45 ]

[ktf]

Zojuist nog wat handigs opgespoord: de tool vmtouch. Hiermee is het mogelijk om het disk cache (in RAM) te manipuleren.

Het idee wat ik nu in mijn hoofd heb: neem 2 HDDs in btrfs raid 1 (zoals ik nu ook heb) en koop in plaats van een SSD veel meer ECC geheugen dan nodig voor een fileserver (32GB ofzo). Vervolgens gebruik ik vmtouch om bestanden die niet in het cache hoeven te worden bewaard eruit te fietsen (zoals bijvoorbeeld bestanden van de beveiligingscamera's) en alle bestanden die wel vlot toegankelijk moeten zijn erin te houden.

Voordelen: vrijwel geen overhead, zeer makkelijk te installeren, wijzigen en onderhouden, en het werkt rechtstreeks op al jarenlang in de kernel ingebouwde systemen, dus geen experimentele of nieuwe technieken.

Nadelen: de grootte van het cache is natuurlijk wel kleiner dan bij gebruik van een SSD

Ik sta nog steeds open voor suggesties, maar ik dacht dat het wel even fijn was om dit te delen

[Ben(V)]

Elk Raid1 heeft dat probleem uiteraard of het nu Btfrs, of mdadm of zfs of wat dan ook is.
Als je last hebt van discrepantie tussen twee disken in een mirror om wat voor reden dan ook, dan is geen enkel Raid 1 systeem in staat om te bepalen welke van de twee disken de juiste informatie heeft.

Ze zeggen overigens dat Raid 1 OK is maar een filesysteem dat pretendeert de next generation filesystem te zijn, maar al meer dan tien jaar niet in staat is om Raid5/6 stabiel te krijgen zou ik nooit mijn data aan toe willen vertrouwen.

[ktf]

Ben(V) schreef op woensdag 14 oktober 2020 @ 09:32:
Elk Raid1 heeft dat probleem uiteraard of het nu Btfrs, of mdadm of zfs of wat dan ook is.
Als je last hebt van discrepantie tussen twee disken in een mirror om wat voor reden dan ook, dan is geen enkel Raid 1 systeem in staat om te bepalen welke van de twee disken de juiste informatie heeft.

Dat is niet waar. btrfs en zfs hebben checksums, dus als één van de twee een onjuiste checksum heeft, is dat de rotte kopie. md heeft geen checksums

[Thralas]

ktf schreef op dinsdag 13 oktober 2020 @ 15:54:
Ik hoop op uw wijze raad Iemand hier met ervaringen, tips of oplossingen?

Bcachefs is een one-man effort en bovenal niet af, toch? Zou daar toch erg terughoudend mee zijn. Zelfs met btrfs heb ik voldoende ellende gehad om het te vermijden en daar zit gewoon een (bescheiden) legertje aan developers achter. Maar als je er geen problemen mee hebt is het een prima optie (jbod of raid 0/1).

Specifiek voor je use case zou je een blik kunnen werpen op ZFS icm. allocation classes. Daarmee kun je alle filesystem metadata (en kleine blocks) op een SSD plaatsen, de rest op een reguliere device. Een HDD voelt daarmee als een SSD, althans voor wat betreft directory listings e.d. Zou je WebDAV ook wel eens kunnen helpen.

Wellicht kan ZFS ook nog wat beteken met een L2ARC, al ben ik daar minder van overtuigd.

[Ben(V)]

Klopt dat Btfrs een checksum heeft, maar bijvoorbeeld een bitrot probleem wordt alleen ontdekt als je gaat scrubben.
Dat is het voordeel van Btfrs, dat kan met mdadm pas als je een raid 5 systeem hebt.

Als je op Btrfs de data gewoon leest krijg je bij toeval of de juiste data of de corrupte data.
Bij Raid 5 krijg je meteen bij het lezen een melding en krijg je wel door middel van de checksum wel de juiste data.

[Q]

Laten we bij het begin beginnen. Je stoort je aan die twee seconden die het duurt om een folder te openen met heel veel kleine files. Ik vind dat eigenlijk nog wel mee vallen, maar ieder zijn voorkeuren

Weet je wel zeker waar dit door komt? We kunnen allerlei oplossingen verzinnen, maar wie weet zit de bottleneck ergens anders. Is dit ook zo met SMB/NFS ?

Wat voor schijven heb je nu in gebruik, wat is de CPU en hoeveel RAM heeft de machine?
Staat de machine altijd aan?

Dat gezegd hebbende, een paar opmerkingen:

- ZFS on Linux is al bijna tien jaar stabiel te noemen. Met ZoL is niets mis en werkt prima onder Ubuntu.
- MDADM werkt ook prima, ik vraag me af waar die corruptie issues werkelijk door kwamen

Verder:

- Hoeveel cache je er ook tegenaan gooit, bij een reboot mag je een find / > /dev/null doen want anders is die cache leeg

- RAM is de beste cache, SSD als Cache, is waarschijnlijk niet echt nuttig, maar misschien als je metadata-only kunt cachen helpt het misschien?

- Als je zo graag checksums wilt zou ik in jouw geval gewoon ZFS gebruiken, maar zonder SLOG of L2ARC (geen SSDs).

- Als je zo graag meer snelheid wil, investeer dan gewoon in SSDs (in RAID1) specifiek voor de mappen met kleine files.

[Renault]

Renault schreef op dinsdag 13 oktober 2020 @ 20:20:
...
Met gebruik van een SSD ben je trouwens ook weer razendsnel live bij een failure als je backup oplossing snel genoeg is (ook op een SSD?). En dat is precies het doel van RAID1: snel weer online zijn.

Ok, had ik erbij moeten zetten: met een SSD waar je backup op staat én een voldoende snelle poort waar die over communiceert. Ik nam aan dat dit duidelijk was, my bad ..

[ Voor 12% gewijzigd door Renault op 14-10-2020 13:22 ]

[ktf]

Ben(V) schreef op woensdag 14 oktober 2020 @ 09:55:
Dat is het voordeel van Btfrs, dat kan met mdadm pas als je een raid 5 systeem hebt.

MD heeft met raid 5 parity, maar geen checksum lijkt me? En al helemaal geen error-correcting code?

Thralas schreef op woensdag 14 oktober 2020 @ 09:54:
Bcachefs is een one-man effort en bovenal niet af, toch? Zou daar toch erg terughoudend mee zijn.

Dat was inderdaad ook van mijn bezwaren, naast dat het toch weer een extra systeem/laag is die erbij komt.

Thralas schreef op woensdag 14 oktober 2020 @ 09:54:
Specifiek voor je use case zou je een blik kunnen werpen op ZFS icm. allocation classes. Daarmee kun je alle filesystem metadata (en kleine blocks) op een SSD plaatsen, de rest op een reguliere device.

Q schreef op woensdag 14 oktober 2020 @ 10:51:
- ZFS on Linux is al bijna tien jaar stabiel te noemen. Met ZoL is niets mis en werkt prima onder Ubuntu.
(...)
- Als je zo graag checksums wilt zou ik in jouw geval gewoon ZFS gebruiken, maar zonder SLOG of L2ARC (geen SSDs).

Ga ik overwegen, maar als ik overga naar ZFS zal ik me er wel even flink in moeten verdiepen, dus btrfs heeft mijn voorkeur.

Q schreef op woensdag 14 oktober 2020 @ 10:51:
Weet je wel zeker waar dit door komt? We kunnen allerlei oplossingen verzinnen, maar wie weet zit de bottleneck ergens anders. Is dit ook zo met SMB/NFS ?

Ik heb even de tijd genomen om het uit te zoeken. Ik heb het find commando getimed op verschillende momenten van de dag. 's ochtends vroeg, na een nacht geen traffic te hebben gehad, duurt het doorzoeken van een specifieke map 4,7 seconden. Voer ik hetzelfde commando een uur later uit, dan is het 0,3 seconde, en doe ik het dan 5 minuten later nog eens dan is het 0,1 seconde.

Het lijkt er m.i. dus op dat het te maken heeft met het ophalen van metadata van de harddisk, welke anders uit RAM gehaald kan worden.

Q schreef op woensdag 14 oktober 2020 @ 10:51:
Wat voor schijven heb je nu in gebruik, wat is de CPU en hoeveel RAM heeft de machine?
Staat de machine altijd aan?

Machine staat altijd aan, CPU is AMD Phenom II X2 550, RAM is 2GB ECC, schijven zijn 2x 1TB Hitachi Deskstar 7200tpm.

Q schreef op woensdag 14 oktober 2020 @ 10:51:
- MDADM werkt ook prima, ik vraag me af waar die corruptie issues werkelijk door kwamen

Het is al enige tijd geleden, maar ik herinner het me dat een harddisk (die ondertussen is vervangen) een aantal moeilijk leesbare blocks had waar uiteindelijk bitrot in kwam, op wat voor manier dan ook. Probleem is dat, zodra er eenmaal verkeerde data op een van de twee schijven stond, mdadm niet kon bepalen welke van de twee kopieën juist was. Btrfs heeft dit probleem niet.

Q schreef op woensdag 14 oktober 2020 @ 10:51:
- Hoeveel cache je er ook tegenaan gooit, bij een reboot mag je een find / > /dev/null doen want anders is die cache leeg

Ik denk dat ik dat maar ga doen. RAM gebruiken is het meest transparant en een cronjob bij het opstarten om wat metadata naar RAM te lezen is weinig werk en weinig risicovol.

[Ben(V)]

Per definitie heeft een Raid 5 een checksum.
Dat is het principe van Raid 5.

Er wordt naast de data een crc parity weggeschreven verdeelt over alle disken.
Als er dan een disk uitvalt kan met de overgebleven data en crc de volledige data recovered worden.

En met die crc wordt dus ook gecontroleerd of de data nog correct is als die data gelezen wordt.
Tevens kan daarmee gescrubd worden om alle data te controleren

Ps Bedenk ook dat elk Cow filesystem meer ruimte nodig heeft en trager is dan bijvoorbeeld Ext4.

[ Voor 10% gewijzigd door Ben(V) op 15-10-2020 09:54 ]

[Q]

ktf schreef op donderdag 15 oktober 2020 @ 09:45:
Machine staat altijd aan, CPU is AMD Phenom II X2 550, RAM is 2GB ECC, schijven zijn 2x 1TB Hitachi Deskstar 7200tpm.

Dat is zo weinig RAM, ik weet het niet zeker maar het zou me niet verbazen dat daardoor regelmatig de metadata uit de cache wordt geflushed door andere activiteiten.

Het is al enige tijd geleden, maar ik herinner het me dat een harddisk (die ondertussen is vervangen) een aantal moeilijk leesbare blocks had waar uiteindelijk bitrot in kwam, op wat voor manier dan ook. Probleem is dat, zodra er eenmaal verkeerde data op een van de twee schijven stond, mdadm niet kon bepalen welke van de twee kopieën juist was. Btrfs heeft dit probleem niet.

Ik vrees dat je bad sectors verward met silent data corruption (bit rot).

Je wilt eigenlijk al nooit in een situatie komen dat je meerdere schijven hebt met bad sectors. Dat zou voorkomen moeten worden door periodieke scrubs en harde schijven met bad blocks snel vervangen bij alerts... Dit is wat je wilt ongeacht het file system.

Misschien dat BTRFS/ZFS er wat beter tegen kan, maar zover wil je het niet laten komen.

Ik denk dat ik dat maar ga doen. RAM gebruiken is het meest transparant en een cronjob bij het opstarten om wat metadata naar RAM te lezen is weinig werk en weinig risicovol.

Ik kan het aanraden. Ik had het in rc.local gegooid. Alleen na de boot is de machine even traag qua storage.