:fill(white):strip_exif()/i/2003943496.jpeg?f=thumbmini)
:strip_exif()/i/1321263566.png?f=thumbmini)
ZFS is idd de target. Inmiddels niet meer, ik heb die machine opgeruimd en de backup naar Acronis gezet. Ik neig er wel naar om weer terug te gaan op ZFS, aangezien de kosten van Acronis inmiddels best wel aantikken (ik zat toen nog niet aan mijn 2.5TB minimale afname per maand en betaalde het toch wel).CurlyMo schreef op vrijdag 19 juni 2020 @ 12:59:
[...]
ZFS is je dus je target en niet je source? Jammer dat dat niet anders gaat.
:strip_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
Au Contraire Mon Capitan!
/u/1176/crop635f8931b2b68_cropped.png?f=community)
Ik snap dat, maar ik vraag me wel af of er geen mooiere alternatieven zouden kunnen zijn. Niet dat we hier een probleem hoeven op te lossen wat je zelf duidelijk aangeeft niet te hebben.
:strip_exif()/u/17028/ico_sphere.gif?f=community)
Nog niet zolang geleden heb ik een nieuwe ZFS NAS gebouwd op basis van XigmaNAS (FreeBSD).
Hierin zitten zes Toshiba MQ03ABB300 schijven maar ik zie zorgwekkende gegevens:
Start_Stop_Count 9
Power_On_Hours 1020
Load_Cycle_Count 25290
Load-in_Time 265
Dus na anderhalf maandje zit het systeem al aan 25.000+ load cycles. Dat is dus gemiddeld 25 cycles per uur. Als dat zo verder gaat, zal elke schijf 200.000 cycles per jaar aantikken.
Wat heb ik al geprobeerd:
- Always On
- Power Management disabled (ook APM op level 128 en 254)
- Zoeken naar firmware update of software tools
Wat kan ik nog doen om te vermijden dat elke 2 minuten de schijven hun kop parkeren ? Ik vermoed dat deze niet meer dan een paar honderdduizend cycles kunnen en het is niet evident 3TB of grotere schijven te vinden die niet SMR zijn, dit zijn de enige
Ik zou het nog even willen uithouden totdat 4TB SSD's betaalbaar zijn
Hierin zitten zes Toshiba MQ03ABB300 schijven maar ik zie zorgwekkende gegevens:
Start_Stop_Count 9
Power_On_Hours 1020
Load_Cycle_Count 25290
Load-in_Time 265
Dus na anderhalf maandje zit het systeem al aan 25.000+ load cycles. Dat is dus gemiddeld 25 cycles per uur. Als dat zo verder gaat, zal elke schijf 200.000 cycles per jaar aantikken.
Wat heb ik al geprobeerd:
- Always On
- Power Management disabled (ook APM op level 128 en 254)
- Zoeken naar firmware update of software tools
Wat kan ik nog doen om te vermijden dat elke 2 minuten de schijven hun kop parkeren ? Ik vermoed dat deze niet meer dan een paar honderdduizend cycles kunnen en het is niet evident 3TB of grotere schijven te vinden die niet SMR zijn, dit zijn de enige
Ik zou het nog even willen uithouden totdat 4TB SSD's betaalbaar zijn
/u/172597/crop5e1225c8b1011.png?f=community)
No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.
@Freeaqingme
/f/image/XapYETedhte2AUjZehiVtPoW.png?f=fotoalbum_medium)
Verder weet ik niet hoe ik het preciezer kan te weten komen. De andere data lijkt namelijk zeer goed te kloppen.
:fill(white):strip_exif()/f/image/XapYETedhte2AUjZehiVtPoW.png?f=user_large)
Verder weet ik niet hoe ik het preciezer kan te weten komen. De andere data lijkt namelijk zeer goed te kloppen.
No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.
@Freeaqingme
Ze zijn inderdaad niet makkelijk om informatie over te vinden. Ik heb het vermoeden dat deze ook niet bedoeld zijn voor de retail maar de OEM markt. De documenten die ik al eerder heb gevonden zijn deze:
https://toshiba.semicon-s...Bxxx-Product-Overview.pdf
https://www.toshiba.co.jp/tech/review/en/01_02/pdf/a07.pdf
Maar daar haal ik geen specs uit die Load Cycles noemt. Ik kan niet verklaren waarom jouw voorbeeld zoveel minder cycles heeft.
Dit zijn de settings die ik al een paar dagen heb staan, met geen verschil in de hoeveelheid cycles per dag.
/f/image/qDZz9tc9fqZYPJbD8c434YOX.png?f=fotoalbum_medium)
Ze zijn inderdaad niet makkelijk om informatie over te vinden. Ik heb het vermoeden dat deze ook niet bedoeld zijn voor de retail maar de OEM markt. De documenten die ik al eerder heb gevonden zijn deze:
https://toshiba.semicon-s...Bxxx-Product-Overview.pdf
https://www.toshiba.co.jp/tech/review/en/01_02/pdf/a07.pdf
Maar daar haal ik geen specs uit die Load Cycles noemt. Ik kan niet verklaren waarom jouw voorbeeld zoveel minder cycles heeft.
Dit zijn de settings die ik al een paar dagen heb staan, met geen verschil in de hoeveelheid cycles per dag.
:fill(white):strip_exif()/f/image/qDZz9tc9fqZYPJbD8c434YOX.png?f=user_large)
[ Voor 5% gewijzigd door Phuncz op 22-06-2020 20:55 ]
:strip_icc():strip_exif()/u/2580/KOMPAKTicoon.jpg?f=community)
:strip_icc():strip_exif()/u/289675/crop6401bf2c85501_cropped.jpg?f=community)
Op het moment heb ik op mijn "oude" thuisserver/nas een aantal datasets met documenten etc. Deze zou ik graag willen overzetten naar mijn nieuwe thuisserver/nas, maar dan wel encrypten (met ZFS native encryption). Alleen, hoe?
Ik heb een (parent) dataset aangemaakt met encryption, en vervolgens een send & receive gedaan: zfs send -R source@snap | zfs receive parent. Verrassend genoeg werkt dit, maar de child heeft dan geen encrypion meer
(uiteraard kwam ik daar pas veel later achter / nadat die had gefaald en ik nog wat pogingen nodig had om een deel met 200GB nieuwe data over te zetten). Nu een nieuwe dataset aangemaakt, die wel netjes de encrypion overneemt van de parent. Maar een nieuwe send & receive mislukt dan weer op dat de dataset al bestaat en -F nodig is. Waarbij ik weer vrees dat een -F ervoor zorgt dat de encryption verloren gaat. Ook een snelle Google zoekopdracht geeft daarbij aan dat het niet zo eenvoudig is om een dataset te repliceren en daarbij encryption te enablen. Mogelijke oplossing die langs kwam was de -R laten vallen en alleen het oudste snapshot over te zetten, en daarna met een -I de rest binnen te halen. Wat zijn dus jullie ervaringen hiermee?
Overigens worden de datasets nu ook al gerepliceerd naar een Orange Pi, liefst kan ik daar de nieuwe snapshots dadelijk aan vast plakken. Maar dat zal vast niet gaan lukken, gezien ik een raw send & receive wil gaan doen die kant op, en dus de encryption behouden, zonder uiteraard de encryption key op de Pi te zetten (later wil ik die Pi dan ook nog buitenshuis gaan plaatsen).
Ik heb een (parent) dataset aangemaakt met encryption, en vervolgens een send & receive gedaan: zfs send -R source@snap | zfs receive parent. Verrassend genoeg werkt dit, maar de child heeft dan geen encrypion meer
(uiteraard kwam ik daar pas veel later achter / nadat die had gefaald en ik nog wat pogingen nodig had om een deel met 200GB nieuwe data over te zetten). Nu een nieuwe dataset aangemaakt, die wel netjes de encrypion overneemt van de parent. Maar een nieuwe send & receive mislukt dan weer op dat de dataset al bestaat en -F nodig is. Waarbij ik weer vrees dat een -F ervoor zorgt dat de encryption verloren gaat. Ook een snelle Google zoekopdracht geeft daarbij aan dat het niet zo eenvoudig is om een dataset te repliceren en daarbij encryption te enablen. Mogelijke oplossing die langs kwam was de -R laten vallen en alleen het oudste snapshot over te zetten, en daarna met een -I de rest binnen te halen. Wat zijn dus jullie ervaringen hiermee?Overigens worden de datasets nu ook al gerepliceerd naar een Orange Pi, liefst kan ik daar de nieuwe snapshots dadelijk aan vast plakken. Maar dat zal vast niet gaan lukken, gezien ik een raw send & receive wil gaan doen die kant op, en dus de encryption behouden, zonder uiteraard de encryption key op de Pi te zetten (later wil ik die Pi dan ook nog buitenshuis gaan plaatsen).
Ik weet niet hoe je APM uitgezet hebt, maar heb je het resultaat ook gechecked?:
Nog niet zolang geleden heb ik een nieuwe ZFS NAS gebouwd op basis van XigmaNAS (FreeBSD).
Hierin zitten zes Toshiba MQ03ABB300 schijven maar ik zie zorgwekkende gegevens:
Start_Stop_Count 9
Power_On_Hours 1020
Load_Cycle_Count 25290
Load-in_Time 265
Dus na anderhalf maandje zit het systeem al aan 25.000+ load cycles. Dat is dus gemiddeld 25 cycles per uur. Als dat zo verder gaat, zal elke schijf 200.000 cycles per jaar aantikken.
Wat heb ik al geprobeerd:
- Always On
- Power Management disabled (ook APM op level 128 en 254)
- Zoeken naar firmware update of software tools
Wat kan ik nog doen om te vermijden dat elke 2 minuten de schijven hun kop parkeren ? Ik vermoed dat deze niet meer dan een paar honderdduizend cycles kunnen en het is niet evident 3TB of grotere schijven te vinden die niet SMR zijn, dit zijn de enige
Ik zou het nog even willen uithouden totdat 4TB SSD's betaalbaar zijn
Zou je eens een
camcontrol identify da1
Overigens is er best wat marge, ik heb 5 stuks HGST Travelstar 5k1000 en ik zat ook niet op te letten, de oudste schijf heeft deze smart stats:
9 Power_On_Hours 0x0012 001 001 000 Old_age Always - 47402 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 60 193 Load_Cycle_Count 0x0012 001 001 000 Old_age Always - 4041753
Ik overweeg op het moment om de schijven te vervangen door jouw MQ03's omdat dit een van de weinige grote PMR 2.5" disks zijn, dus als we het bij jou gefixt krijgen dan kan ik met een gerust hart schijven gaan vervangen
12x 280Wp ZW, 12x 280Wp ZO, Zubadan SHW80YAA 8kW, Zehnder Q450 ERV
Ik zie je bericht nu pas. Bizar is dat deze APM level 128 aanduidt terwijl het in de web-interface staat op 254.:
[...]
Ik weet niet hoe je APM uitgezet hebt, maar heb je het resultaat ook gechecked?
Zou je eens eenwillen doen?camcontrol identify da1
Overigens is er best wat marge, ik heb 5 stuks HGST Travelstar 5k1000 en ik zat ook niet op te letten, de oudste schijf heeft deze smart stats:
9 Power_On_Hours 0x0012 001 001 000 Old_age Always - 47402 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 60 193 Load_Cycle_Count 0x0012 001 001 000 Old_age Always - 4041753
Ik overweeg op het moment om de schijven te vervangen door jouw MQ03's omdat dit een van de weinige grote PMR 2.5" disks zijn, dus als we het bij jou gefixt krijgen dan kan ik met een gerust hart schijven gaan vervangen
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
| pass2: <TOSHIBA MQ03ABB300 JP050U> ATA8-ACS SATA 3.x device pass2: 600.000MB/s transfers, Command Queueing Enabled protocol ATA8-ACS SATA 3.x device model TOSHIBA MQ03ABB300 firmware revision JP050U serial number 18KAW0OIT WWN *** additional product id cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 4096, offset 0 LBA supported 268435455 sectors LBA48 supported 5860533168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA5 media RPM 5400 Zoned-Device Commands no Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes Native Command Queuing (NCQ) yes 32 tags NCQ Priority Information no NCQ Non-Data Command no NCQ Streaming no Receive & Send FPDMA Queued no NCQ Autosense no SMART yes yes security yes no power management yes yes microcode download yes yes advanced power management yes yes 128/0x80 automatic acoustic management no no media status notification no no power-up in Standby yes no write-read-verify no no unload yes yes general purpose logging yes yes free-fall no no sense data reporting no no extended power conditions no no device statistics notification no no Data Set Management (DSM/TRIM) no Trusted Computing no encrypts all user data no Sanitize no Host Protected Area (HPA) yes no 5860533168/5860533167 HPA - Security yes no Accessible Max Address Config no |
Met
code:
heb ik APM uitgeschakeld, nu moet ik het in de gaten houden. Momenteel 1.300 Power On Hours en 34.000 Load Cycle Count gemiddeld. Ik was eigenlijk van plan dit te laten varen en te hopen dat het minimaal 3 jaren uithoudt. Maar als jij met 4 miljoen cycles het nog steeds trekt, moet ik me misschien geen zorgen maken.1
| sudo camcontrol apm da1 |
Ik kan de schijven wel aanraden met mijn korte ervaring. Ze zijn stil: tot nu toe heb ik ze steeds moeten herkennen of ze aan staan door trilling te voelen in de drive cage. Qua performance mag ik ook niet klagen in RAID-Z2, zpool scrub ging aan 350MB/sec als ik enkel de used space tel, full array is dat 470MB/sec.
:strip_icc():strip_exif()/u/96515/FireArrows.jpg?f=community)
Bluh! Jaren geleden een (degraded) NAS opgebouwd met ZFSGuru (onder water FreeBSD), memory disk aangemaakt, pool aangemaakt, en na data transfer een HD toegevoegd en resilver gedraaid. Appeltje eitje!
Inmiddels heb ik een Microserver Gen8 erbij, en wilde ik hetzelfde trucje doen, maar dan... gebaseerd op Debian Buster en ZFS-on-linux. Maar... eenzelfde degraded NAS opbouwen in Debian is wat lastiger.... zo blijkt!
Heb volgens deze handleiding een ramdisk aangemaakt met het commando:
Hij is daarna zichtbaar als ik het volgende commando uitvoer: echter als ik vervolgens een ZPOOL wil aanmaken dan kan ik deze niet gebruiken. Ik zie de ramdisk helaas óók niet in /dev terug komen helaas. Merk op, ik voer het commando middels "sudo" uit, dus het kan niet aan de rechten liggen m.i.
Toen dacht ik, ik zet een zpool op met een USB stick, degrade deze, en replace hem daarna met de Ramdisk, maar ook dat mocht niet (logisch verder, maar wilde het even uitsluiten).
Heeft één van jullie een idee wat ik verkeerd doe in deze?
Inmiddels heb ik een Microserver Gen8 erbij, en wilde ik hetzelfde trucje doen, maar dan... gebaseerd op Debian Buster en ZFS-on-linux. Maar... eenzelfde degraded NAS opbouwen in Debian is wat lastiger.... zo blijkt!
Heb volgens deze handleiding een ramdisk aangemaakt met het commando:
mount -t tmpfs -o size=512m tmpfs /mnt/ramdisk
Hij is daarna zichtbaar als ik het volgende commando uitvoer:
df -h
Toen dacht ik, ik zet een zpool op met een USB stick, degrade deze, en replace hem daarna met de Ramdisk, maar ook dat mocht niet (logisch verder, maar wilde het even uitsluiten).
Heeft één van jullie een idee wat ik verkeerd doe in deze?
Wanna play?
/u/38159/DirkJan.png?f=community)
Wil je nou een RAM-disk gebruiken als ZFS pool? Ben je dan niet bezig om de hele filosofie achter ZFS om zeep te helpen?:
Bluh! Jaren geleden een (degraded) NAS opgebouwd met ZFSGuru (onder water FreeBSD), memory disk aangemaakt, pool aangemaakt, en na data transfer een HD toegevoegd en resilver gedraaid. Appeltje eitje!
Inmiddels heb ik een Microserver Gen8 erbij, en wilde ik hetzelfde trucje doen, maar dan... gebaseerd op Debian Buster en ZFS-on-linux. Maar... eenzelfde degraded NAS opbouwen in Debian is wat lastiger.... zo blijkt!
Heb volgens deze handleiding een ramdisk aangemaakt met het commando:mount -t tmpfs -o size=512m tmpfs /mnt/ramdisk
Hij is daarna zichtbaar als ik het volgende commando uitvoer:echter als ik vervolgens een ZPOOL wil aanmaken dan kan ik deze niet gebruiken. Ik zie de ramdisk helaas óók niet in /dev terug komen helaas. Merk op, ik voer het commando middels "sudo" uit, dus het kan niet aan de rechten liggen m.i.df -h
Toen dacht ik, ik zet een zpool op met een USB stick, degrade deze, en replace hem daarna met de Ramdisk, maar ook dat mocht niet (logisch verder, maar wilde het even uitsluiten).
Heeft één van jullie een idee wat ik verkeerd doe in deze?
QnJhaGlld2FoaWV3YQ==
:strip_exif()/u/70909/BlueKachina_60x60.gif?f=community)
De ZFSGuru manier gaat uit van een lazy provisioning. Dus een memory disk met dezelfde grootte als de HDD's. Door lazy provisioning neemt die geen ruimte in bij het aanmaken van de pool. Je moet opnieuw voor het vullen de memory disk verwijderen.:
Heeft één van jullie een idee wat ik verkeerd doe in deze?
Sinds de 2 dagen regel reageer ik hier niet meer
Nee hoor, dit is enkel voor de initialisatie van de pool. Daarna gooi ik de ramdisk er direct uit. Tijdens de initiële data transfer is de pool dan inderdaad degraded, pas na overdracht heb ik een HD over en kan ik de pool resilveren. Aangezien je niet van een 3-disk Z1 naar een 4-disk Z1 kunt uitbreiden is dit een workaround.
Hij geeft dan de volgende melding;
cannot open 'tmpfs': no such device in /dev must be a full path or shorthand device name
Terwijl ik bij hem duidelijk zie staan bij df -h:
Filesystem Size Used Avail Use% Mounted on udev 7.8G 0 7.8G 0% /dev tmpfs 1.6G 9.3M 1.6G 1% /run /dev/md0 59G 4.1G 52G 8% / tmpfs 7.9G 0 7.9G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup tank 42G 128K 42G 1% /tank tmpfs 1.6G 4.6M 1.6G 1% /run/user/1000 tmpfs 3.0T 0 3.0T 0% /mnt/ramdisk
Klopt, ben ik ook van plan
Wanna play?
En hoe doe ik dat?
Zojuist met wat googlen kwam ik hier op uit, maar als ik de optie -o loop toevoeg dan krijg ik de melding "mount: bad usage".Het hele commando wordt dan
mount -t tmpfs -o loop,size=3T tmpfs /mnt/ramdisk
Wanna play?
Waarom een ramdisk backend en niet een bestand?:
[...]
En hoe doe ik dat?
root@pve:/# df -h /tmp
Filesystem Size Used Avail Use% Mounted on
rpool/ROOT/pve-1 5.9G 3.0G 2.9G 52% /
root@pve:/# truncate -s 3T /tmp/a
root@pve:/# truncate -s 3T /tmp/b
root@pve:/# truncate -s 3T /tmp/c
root@pve:/# zpool create temp raidz1 /tmp/a /tmp/b /tmp/c
root@pve:/# zpool list temp
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
temp 8.98T 205K 8.98T - - 0% 0% 1.00x ONLINE -
root@pve:/# zpool status temp
pool: temp
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
temp ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
/tmp/a ONLINE 0 0 0
/tmp/b ONLINE 0 0 0
/tmp/c ONLINE 0 0 0
errors: No known data errors
Sinds de 2 dagen regel reageer ik hier niet meer
Yup...! Instant
Nu ff verder puzzelen met Samba... Windows werkt totaal niet mee. Vanaf een iOS app werkt het inloggen, via samba-client ook, maar Windows geeft aan dat het wachtwoord onjuist is vreemd genoeg.
[ Voor 22% gewijzigd door F-Tim op 06-07-2020 23:11 ]
Wanna play?
Zoooo! Inmiddels de setup op de 2de locatie draaiende ben wel benieuwd of ik iets fout heb gedaan, de resilver performance van ZFS-on-linux is namelijk wel echt véél lager dan die op FreeBSD.
Ter info, mijn eigen oude systeem, haalt met een Pentium G1840 en 8GB (non-ecc) geheugen met 6x4TB disks een resilver performance van +/- 500Mb/s op FreeBSD.
Het nieuwe systeem wat ik heb gebouwd doet met een G2020T en 16GB (ECC) geheugen met 4x3TB disks (op een 4xSATA - SAS connector) een resilver performance van 25Mb/s op Debian met de laatste zfs-on-linux.
Kan ik nog iets aan deze performance doen?
En... als ik ná de resilver een corrupt bestand heb, dit bestand verwijder, zpool clear uitvoer, is die nieuwe resilver dan ook verplicht? Hij loopt nu nl. een 2de resilver, maar ik zou verwachten dat verwijderen van een bestand voldoende zou zijn.
ben wel benieuwd of ik iets fout heb gedaan, de resilver performance van ZFS-on-linux is namelijk wel echt véél lager dan die op FreeBSD.Ter info, mijn eigen oude systeem, haalt met een Pentium G1840 en 8GB (non-ecc) geheugen met 6x4TB disks een resilver performance van +/- 500Mb/s op FreeBSD.
Het nieuwe systeem wat ik heb gebouwd doet met een G2020T en 16GB (ECC) geheugen met 4x3TB disks (op een 4xSATA - SAS connector) een resilver performance van 25Mb/s op Debian met de laatste zfs-on-linux.
Kan ik nog iets aan deze performance doen?
En... als ik ná de resilver een corrupt bestand heb, dit bestand verwijder, zpool clear uitvoer, is die nieuwe resilver dan ook verplicht? Hij loopt nu nl. een 2de resilver, maar ik zou verwachten dat verwijderen van een bestand voldoende zou zijn.
Wanna play?
:strip_icc():strip_exif()/u/65843/chef60x60.jpg?f=community)
:strip_icc():strip_exif()/u/75828/sid.jpg?f=community)
De vereiste volg ik het nog, maar DKMS is geen onderdeel van zfs toch? Althans... als het staat voor "Dynamic Kernel Module Support", dan is het toch generieker? Er zullen immers ook meer DKMS modules zijn? En als dat zo is, hoe zou ik kunnen weten dat ik DKMS nu met de buster-backports moet installeren voor mijn "verouderde zfs" vraagstuk?
Ik probeer gewoon langzaam meer van Linux te begrijpen, en deze verbintenis zie ik nog niet direct, vandaar ook de vraag
Wanna play?
@P5ycho Ik heb eigenlijk besloten er niet meer naar te kijken totdat er eentje kapot gaat. Momenteel staan ze allemaal rond de 45.000 cycles na 1.780 uren, wat ongeveer 25 cycles per uur is. Volgens de SMART gegevens zitten ze op 96% van hun leven na 74 dagen, wat zou betekenen dat ze na een jaar van dit gedrag op 80% van hun verwachte levensduur. Dat zou neerkomen op 5 jaar 24/7 dus ik ga er niet meer om miepen
Ik zou niet te lang wachten, volgens Azerty.nl heeft de leverancier nog "maar" 218 stuks momenteel, dat was eerder deze week 230 en eerder deze maand nog 300+. De goedkoopste is momenteel bij SiComputers:
pricewatch: Toshiba MQ03ABB300, 3TB
Beschouw ze dan ook als een koopje (25€/TB in 2,5" verruit de voordeligste) en koop ook een cold spare of twee want ik verwacht dat ze na de zomer nergens meer te krijgen zijn.
Ik zou niet te lang wachten, volgens Azerty.nl heeft de leverancier nog "maar" 218 stuks momenteel, dat was eerder deze week 230 en eerder deze maand nog 300+. De goedkoopste is momenteel bij SiComputers:
pricewatch: Toshiba MQ03ABB300, 3TB
Beschouw ze dan ook als een koopje (25€/TB in 2,5" verruit de voordeligste) en koop ook een cold spare of twee want ik verwacht dat ze na de zomer nergens meer te krijgen zijn.
:strip_icc():strip_exif()/u/38800/i_m_weasel-char.jpg?f=community)
Kleine update rondom mijn SMR Pool:
Gister was ik zo slim om met wat downloads mijn pool vol te laten lopen. Dat was niet erg handig
Load van het systeem steeg naar 15, en was bijna compleet onbestuurbaar. Gelukkig houdt ZFS tegenwoordig wat meer reserve ruimte vrij (15MB ofzo), waardoor ik nog wel files kon verwijderen om weer ruimte te maken.
De SMR pool kan er erg slecht tegen om vol te zijn, en daarnaast nog behoorlijk wat IO om zijn oren te krijgen.
Ik zag IOwait van > 95%, waarbij de latency ook behoorlijk op aan het lopen was (openen van een text file met vim op de array duurde > 10 seconden).
Vandaag dus maar besloten om mijn 'incoming' downloads in ieder geval van de array af te gaan halen, zodat de array iets meer rust krijgt.
Mocht er dus nog discussie zijn of SMR schijven icm ZFS verstandig is in je server, weet dan, dat je niet een heel druk download bestaan er op na moet houden op zo'n pool
* FireDrunk gaat kijken of de FusionIO kaart die hij ooit eens voor een prikkie van iemand overgenomen heeft, hier kan helpen
Gister was ik zo slim om met wat downloads mijn pool vol te laten lopen. Dat was niet erg handig
Load van het systeem steeg naar 15, en was bijna compleet onbestuurbaar. Gelukkig houdt ZFS tegenwoordig wat meer reserve ruimte vrij (15MB ofzo), waardoor ik nog wel files kon verwijderen om weer ruimte te maken.
De SMR pool kan er erg slecht tegen om vol te zijn, en daarnaast nog behoorlijk wat IO om zijn oren te krijgen.
Ik zag IOwait van > 95%, waarbij de latency ook behoorlijk op aan het lopen was (openen van een text file met vim op de array duurde > 10 seconden).
Vandaag dus maar besloten om mijn 'incoming' downloads in ieder geval van de array af te gaan halen, zodat de array iets meer rust krijgt.
Mocht er dus nog discussie zijn of SMR schijven icm ZFS verstandig is in je server, weet dan, dat je niet een heel druk download bestaan er op na moet houden op zo'n pool
* FireDrunk gaat kijken of de FusionIO kaart die hij ooit eens voor een prikkie van iemand overgenomen heeft, hier kan helpen
Even niets...
Ja, exact. Ik maak veel gebruik van Torrents, waar het best onhandig is om de data lang op de SSD's te laten staan terwijl je aan het seeden bent. Als het op 1 array staat, kunnen tools als Sonarr en Radarr hardlinks gebruiken om de data toch nog te kunnen blijven seeden.
Die functionaliteit moet ik nu dus opgeven
Hardlinks tussen verschillende devices kunnen helaas niet. Binnen een ZFS pool kan dat wel.
Die functionaliteit moet ik nu dus opgeven
Hardlinks tussen verschillende devices kunnen helaas niet. Binnen een ZFS pool kan dat wel.
Even niets...
Werken hardlinks niet alleen op hetzelfde filesystem / mountpoint / ...? En gezien je potentieel op 1 ZFS pool meerdere datasets hebt zouden ze dan ook niet meer werken?:
Ja, exact. Ik maak veel gebruik van Torrents, waar het best onhandig is om de data lang op de SSD's te laten staan terwijl je aan het seeden bent. Als het op 1 array staat, kunnen tools als Sonarr en Radarr hardlinks gebruiken om de data toch nog te kunnen blijven seeden.
Die functionaliteit moet ik nu dus opgeven
Hardlinks tussen verschillende devices kunnen helaas niet. Binnen een ZFS pool kan dat wel.
* RobertMe heeft "dat" weer in Docker draaien, en ook dan werken hardlinks niet, ondanks dezelfde onderliggende ZFS dataset (maar als losse volumes in de container).
Edit:
Overigens komen die ~10 seconde waits me wel aardig bekend voor van toen ik een SMR in mirror had (met PMR) en database er op draaide.
[ Voor 7% gewijzigd door RobertMe op 29-07-2020 11:39 ]
Alleen werd dat nooit uitgelegd in zuinige server topic. Daarom toen één HDD uit mirror bad sectors vertoonde die Seagate gekocht, maar dat werkte dus niet echt.... Nu nieuwe server op gezet met 3x shucked WD (3,5" PMR dus) terwijl ik nu LXC containers heb die vanaf SSD draaien en HDDs alleen bulk storage doen. Dus juist nu in nieuwe setup had ik wel voor SMR kunnen gaan. Maar ach, die Seagate hangt nu aan Orange Pi voor backup. Alleen nog een case ontwerpen en printen en dan offsite plaatsen. Dan heeft die ook nog een goede toepassing gekregen.:
[...]
Ook een mooi voorbeeld van right tool for the job
Misschien interessant om een special device te gebruiken voor metadata en kleine records ipv een 2e pool?:
Ja, exact. Ik maak veel gebruik van Torrents, waar het best onhandig is om de data lang op de SSD's te laten staan terwijl je aan het seeden bent. Als het op 1 array staat, kunnen tools als Sonarr en Radarr hardlinks gebruiken om de data toch nog te kunnen blijven seeden.
Die functionaliteit moet ik nu dus opgeven
Hardlinks tussen verschillende devices kunnen helaas niet. Binnen een ZFS pool kan dat wel.
Ben even je setup kwijt, maar bijv:
5x raidz1 smr
Recordsize=2M of 4M (512K of 1M per disk)
2x SSD, special:metadata+records <2M
[ Voor 9% gewijzigd door P5ycho op 30-07-2020 22:28 ]
12x 280Wp ZW, 12x 280Wp ZO, Zubadan SHW80YAA 8kW, Zehnder Q450 ERV
Ik draai al een tijdje FreeNAS. Helemaal blij mee. Tot m'n moederboard overleed. Allemaal opgelost nu hardware weer draaien. Ik heb een apart topic aangemaakt maar ben zo brutaal 'm hier ook even te linken:
Zpool import faalt(one or more devices were being resilverd)
Kort door de bocht:
Hier de output van zpool import (en zpool import -f geeft FreeNAS problemen en een panic):
root@freenas[~]# zpool import
pool: six4tb
id: 13928668106559313930
state: DEGRADED
status: One or more devices were being resilvered.
action: The pool can be imported despite missing or damaged devices. The
fault tolerance of the pool may be compromised if imported.
config:
six4tb DEGRADED
raidz1-0 DEGRADED
gptid/39dbdb0d-8506-11e7-bbff-d050996ff8e2 ONLINE
gptid/75e759d8-a341-11ea-9020-d050996ff8e2 ONLINE
gptid/bdb2785d-f5c9-11e9-bb0c-d050996ff8e2 ONLINE
gptid/b7e766d9-33df-11ea-abdb-d050996ff8e2 ONLINE
gptid/bc6a0659-4031-11ea-b4f8-d050996ff8e2 ONLINE
replacing-5 UNAVAIL insufficient replicas
13571676615721927902 UNAVAIL cannot open
18182716167874336493 UNAVAIL cannot open
Als ik dit zo bekijk zijn er dus 5 schijven online en 1 niet? Die ene schijf (misschien dom bedenk ik me nu) heb ik gewiped. Ik heb de oude schijf ook nog nog voor de resilver maar ben bang dat ook niet meer een geheel ervan ziet, al geprobeerd. Ik hoopte dat ik 'm wel kon importeren zo en dat resilveren weer opnieuw start. .... Niet dus
. Dat resilveren is dus niet goed gegaan. Kan ik van deze pool met 5 van de 6 schijven niet een benaderbare pool maken? En dan weer schijf 6 toevoegen en dan resilveren (en die laten afmaken)
Ik hoop echt dat iemand een idee heeft hoe ik deze pool weer online kan krijgen. Hartelijk dank voor het lezen en meedenken
ik raak er een beetje gefrustreerd van ;-(
Zpool import faalt(one or more devices were being resilverd)
Kort door de bocht:
Hier de output van zpool import (en zpool import -f geeft FreeNAS problemen en een panic):
root@freenas[~]# zpool import
pool: six4tb
id: 13928668106559313930
state: DEGRADED
status: One or more devices were being resilvered.
action: The pool can be imported despite missing or damaged devices. The
fault tolerance of the pool may be compromised if imported.
config:
six4tb DEGRADED
raidz1-0 DEGRADED
gptid/39dbdb0d-8506-11e7-bbff-d050996ff8e2 ONLINE
gptid/75e759d8-a341-11ea-9020-d050996ff8e2 ONLINE
gptid/bdb2785d-f5c9-11e9-bb0c-d050996ff8e2 ONLINE
gptid/b7e766d9-33df-11ea-abdb-d050996ff8e2 ONLINE
gptid/bc6a0659-4031-11ea-b4f8-d050996ff8e2 ONLINE
replacing-5 UNAVAIL insufficient replicas
13571676615721927902 UNAVAIL cannot open
18182716167874336493 UNAVAIL cannot open
Als ik dit zo bekijk zijn er dus 5 schijven online en 1 niet? Die ene schijf (misschien dom bedenk ik me nu) heb ik gewiped. Ik heb de oude schijf ook nog nog voor de resilver maar ben bang dat ook niet meer een geheel ervan ziet, al geprobeerd. Ik hoopte dat ik 'm wel kon importeren zo en dat resilveren weer opnieuw start. .... Niet dus
. Dat resilveren is dus niet goed gegaan. Kan ik van deze pool met 5 van de 6 schijven niet een benaderbare pool maken? En dan weer schijf 6 toevoegen en dan resilveren (en die laten afmaken)Ik hoop echt dat iemand een idee heeft hoe ik deze pool weer online kan krijgen. Hartelijk dank voor het lezen en meedenken
ik raak er een beetje gefrustreerd van ;-(
/u/173821/crop5942840a66f85_cropped.png?f=community)
Na een klein onderhoudje had ik per ongeluk één van de connectors los van de storage controller en kon een aantal schijven niet meer zien. Server uit, connector goed aangesloten, alle schijven gedecteerd maar had toen mijn zpool als DEGRADED. Eén van de schijven was niet goed opgenomen in de pool, heb deze maar replaced want ik kreeg het niet in orde. De schijf is geresilvered, zpool is nu ONLINE, maar nu heb ik dit:
/f/image/zm2MciUzJfg8L0zijb8vem9M.png?f=fotoalbum_large)
(da7 is unknown/unformatted)
/f/image/QXpRHPsdfTF7OZSh7wAMfShG.png?f=fotoalbum_large)
/f/image/2HiBPHcxo33Gc3hYMQ1axlqF.png?f=fotoalbum_large)
Enig idee hoe ik dit oplos ?
:fill(white):strip_exif()/f/image/zm2MciUzJfg8L0zijb8vem9M.png?f=user_large)
(da7 is unknown/unformatted)
:fill(white):strip_exif()/f/image/QXpRHPsdfTF7OZSh7wAMfShG.png?f=user_large)
:fill(white):strip_exif()/f/image/2HiBPHcxo33Gc3hYMQ1axlqF.png?f=user_large)
Enig idee hoe ik dit oplos ?