Ni med Seagate IronWolf, vad är eran Load_cycle_count ?

Load cycle count är Inga problem idag. Vi snackar hundratusentals parkeringar innan man kan se det som ett problem. Disken tar inte slut i förtid, för då hade den inte parkerat så ofta som den gör. Alltså för vad är "förtid"? Ger tillverkaren en garanti på 3 eller 5 år så är ju allt upp till det inte i förtid. Jag tror att mina ironwolf har en spec på att den ska klara ungefär 600 000 parkeringar. Det täcker garantin på 3 år med råge.

Men om det är så enkelt att bara "låta det flyga", varför ser inte tillverkaren till att de flyger i firmware? Om det är så skadligt menar jag. Har man ovanligt mycket parkeringar så kan man ju börja fundera men snackar vi inte 10 000 i veckan så är det ingen större fara. Min nyaste IronWolf som sitter som parity har 423 load cycle count sedan 2018-12-25. IronWolf är ju just NAS-diskar. Om frekventa parkeringar är ett så pass stort problem så skulle de väl inte parkera så ofta som de gör?

Du skriver att FreeBSD verkar parkera ofta, vad är ofta? Vad har du för siffror? Jag kör Unraid (slackware) och ser inte det problemet.

Edit: Det finns en del trådar om detta på Unraids forum. I en tråd pratar de om att någon ser 400 lcc på 1 vecka. Svaret på det är att det då tar 30 år att nå 600 000. https://forums.unraid.net/topic/66842-seagate-ironwolf-8-tb-q...

Edit 2: Jag låter ju mina diskar sova när de inte används så de sover stora delar av dygnet. Det diskuteras ju också för fullt om man ska låta de snurra 24/7 eller låta diskarna sova. Inget bra svar finns på vilket som är bäst. Eller sämst. Jag har några Samsung-diskar som jag pensionerade nyligen. De har gått 24/7 i 5,5 år.

423 lcc på 12 dagar = ca 35 om dagen. 1 år = 12 866 = 46 år innan jag når 600000. Det beror så klart på hur mycket man använder disken. Jag har inte så stor användning än så länge men eftersom att detta är en paritetsdisk så skrivs det ju till den så fort något skrivs till någon av de andra diskarna i arrayen.

@wasabi: Jo! Absolut! Håller med förstås men om de håller garantitiden ut så tar de ju inte slut "i förväg" eftersom att de bara garanterar x antal år. Det var så jag menade. Jag har inte varit med om någon disk som inte har klarat garantitiden + 2-4 år (av mina egna diskar alltså). Förutom diskar som har blivit skadade av andra orsaker, typ tappad bärbar osv.

Ja, det beror ju på hur systemet använder disken, hur mycket DU använder den och så vidare. Har du 6000 på 12 månader så tar det dig 100 år att nå 600000. Hade detta varit ett normalt och stort problem så hade man inte låtit disken parkera så ofta, alltså i firmware. Om det är bättre att de flyger, varför parkerar man över huvud taget? Att parkera när disken spinner ner förstår jag, men annars? Det låter inte så logiskt bara. Kanske strömförbrukning och temperatur kan vara inblandade.

För den orolige så kan 'smartctl -s apm,off /dev/sdX' vid varje start också dra ner på antalet lcc's. Förstår det som att vissa diskar parkerar efter 8 sekunders inaktivitet.

En del parkerar efter 8 sekunder oavsett om du spinner ner disken eller inte. Det hänger förstås på vad ditt system och din användning gör med disken. Jag har ytterst sällan sett diskar som havererat enbart pga högt antal lcc's. Om jag skulle låta den snurra istället för att somna så skulle det inte påverka lcc eftersom att den skulle parkera huvudet efter 8 sekunder och sen om jag inte accessar disken alls under lång tid så kommer den låta huvudet stå parkerat. Då kan disken lika gärna sova istället.

"Om det är så ofarligt att parkera huvudena och det inte innebär slitage, varför är det något som loggas i SMART ?
Om det inte innebär något slitage, varför specificerar tillverkarna hur många LCC disken skall klara ?"

Jag har inte sagt att det är ofarligt men har man inte enormt med lcc så är det inget problem om specen ligger på 600000. Självklart så sliter det när mekaniska delar flyttar på sig men fortfarande, 600 000.

Vad har du för för siffror själv?

Edit: FreeNAS körs ju på FreeBSD. De kanske optimerar något, jag vet inte.
Tips är alltid bra men att börja greja med inställningarna är onödigt så länge man inte ser enorma siffror på lcc. För att veta om man behöver oroa sig så är det bra att kolla vad man har för siffror, kolla vad disken har för spec och räkna lite på om det ens är ett problem. För MIG så är det absolut inget problem. Med min användning så snackar vi ändå 40 år innan jag når gränserna. Samtidigt så betyder det inte heller att disken stendör direkt när jag når 600000. LCC i SMART är ett värde för "old age". Det ligger inte under "pre-fail".

@lambdan: Du behöver alltså inte oroa dig. 23 år innan du når 600000 på den första du nämner.

@Karaff: Ja, alltså kort stund är en grej, det kan ju bli så om något inte skriver data konstant, att det tar 8 sekunder mellan omgångarna. Det intressanta är ditt värde över kanske, 24 timmar. Eller kanske totalt plus driftstid. Ser du tusentals parkeringar på ett dygn så skulle jag också fundera. Kolla lite på vad jag gjorde just den dagen. En kontroll av paritet kräver rätt mycket men då hinner den inte parkera eftersom att disken används hela tiden.

Edit: Jag har också googlat mycket om just lcc. De flesta har ändå inget problem om man gräver lite bland siffrorna. Folk oroar sig när värdet är mer än 0 ungefär. Vana vid att reallocated sector count och andra "farliga" värden helst ska vara 0. Så, då oroar sig folk för alla värden som inte är 0 och inte har ett direkt beskrivande namn. Som tex "temperature celsius". Jag har en massa siffror på "seek error rate". Kändes farligt innan jag googlade och såg att det var normalt.

I Unraid så ser du dina smartvärden lätt i administrationen. Den varnar också när vissa värden börjar öka. Den varnar bara för värden som anses vara viktiga. LCC är inte med där men det är nog mycket för att de olika tillverkarna har olika gränser som inte finns med i smart-infon som disken levererar. Det är väl inte heller ett värde som kan ge fail på smart.

Attribute = 5 Reallocated sectors count
Attribute = 187 Reported uncorrectable errors
Attribute = 188 Command time-out
Attribute = 197 Current pending sector count
Attribute = 198 Uncorrectable sector count
Attribute = 199 UDMA CRC error rate

Jag fick några UDMA CRC-fel när jag bytte hårdvara. Bytte alla SATA-kablar till nya och problemet försvann.

Latency på en NAS-disk kanske inte är hela världen. IronWolf som systemdisk känns inte helt optimalt. Men alla är vi olika.

"Du har fortfarande inte svarat på frågan, VARFÖR skulle jag vilja ha även "bara" 100-tals parkeringar på min disk, när det inte innebär någon fördel, bara slitage och latency ?"

Jag vet inte vad jag ska svara på det. Ja, varför skulle du vilja ha det? Du får ha hur många du vill. Det är väl upp till dig men fortfarande så är det inte ett stort problem som man normalt behöver oroa sig för. Jag kan för lite för att veta VARFÖR de parkerar så frekvent. Det bör finnas en anledning.

Antar att det här också är OT men,
Disktemperatur oroar Unraid. Det är en separat inställning för alla diskar eller också per disk. En temp vid varning och en vid kritisk. Det är inte smart som bestämmer när det ska varnas. Timmar i drift varnar de förstås inte för eftersom att det inte heller är ett värde som smart skulle ge en fail på. Kör två SSDs i RAID1 (cache i unraid) där allt som rör VMs, Dockers och tillhörande appdata ligger. IronWolf-diskarna och de övriga diskarna är parity + array. Unraid har också en mover-funktion. Du kan välja så att allt du sparar ska sparas på cache och sen väljer du när mover ska köras (helst när man sover då och när servern har lite att göra) som flyttar alla filer från ssd till array. Du märker ingen skillnad. Förutom att när du skriver saker till servern så går det snabbt eftersom att det först går till SSD och sedan till array vid bättre tidpunkt eftersom att paritetsberäkning + data är låååångsamt.

Edit: Jag oroar mig när de värden som Unraid varnar för är över 0. Behöver jag gå till en psykolog?
Jag oroade mig också för TBW för mina SSD-diskar innan jag läste på och fattade att 150 TBW räcker väldigt länge ändå men jag har valt att inte använda mover för att spara lite på TBW.

Ja, så är det. Det är garantin jag tänker på mest. Jag kör 860 EVO 250GB (ej pro) med en TBW på 150. De har ju 5 år ELLER 150 TBW, det som kommer först. Antagligen så skulle jag kunna köra på hårt och köra allt till cache för att sen låta movern flytta det utan problem men jag har inte det behovet. Det gör inget att det tar lite längre tid att skriva direkt till array. Edit: Kör också en spinner ansluten via USB3 som används unassigned (för att undvika seg paritetsberäkning för temporär lagring). Där ligger tillfälliga filer för transcoding (som tas bort) och tempdata som ändå flyttas till array sen när appen är klar så att säga. Detta för att spara lite på tbw. Kör också en gammal Intel (520 series) på min desktop. Det är något konstigt med smartvärdet på den dock men den har "bara" 28 tbw.