Nattliga biblioteksskanningar fortsätter att väcka hårddiskar: Så minskar du dem

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Overnight Library Scans Keep Waking Hard Drives: How to Reduce Them

Minska diskväckningar över natten genom att identifiera den exakta schemalagda uppgiften som använder mediefiler och sedan begränsa dess frekvens, omfattning eller filnivåarbete.

En medieserver kan väcka vilande hårddiskar även när databasen och cachen ligger på SSD, eftersom en schemalagd biblioteksskanning kan gå igenom kataloger, läsa av filer, uppdatera omslagsbilder, generera förhandsvisningar, validera sökvägar eller bearbeta objekt som aldrig når ett stabilt tillstånd. Börja med att koppla den första diskåtkomsten till en uppgift och en loggpost. Att ändra vilotimers innan utlösaren har bevisats döljer vanligtvis mönstret utan att minska den underliggande läsningen.

Bevisa vilken schemalagd uppgift som väcker diskarna

Notera den exakta väckningstiden från disktelemetri, systemloggar eller effektövervakning och jämför den med medieserverns historik över schemalagda uppgifter. Inaktivera endast en misstänkt uppgift under en natt så att resultatet fortfarande kan kopplas till rätt orsak.

En Jellyfin-rapport visade att den schemalagda biblioteksskanningen upprepade gånger bearbetade hela biblioteket två gånger per dag och ägnade timmar åt att läsa av media. Den användbara ledtråden var att samma fullständiga skanning fortsatte att upprepas, snarare än att det handlade om en enstaka uppspelningsförfrågan.

Om diskarna vaknar innan biblioteksskanningen startar bör du kontrollera en annan uppgift, till exempel extrahering av kapitelbilder, generering av trickplay-filer, introanalys, uppdatering av metadata, säkerhetskopiering, SMART-testning, filsystemsrensning eller en nedladdningsorganiserare. Skyll inte på medieservern förrän dess process eller container finns med i bevisen för den första åtkomsten.

Skilj fullständiga biblioteksskanningar från realtidsövervakning

Kontrollera om biblioteket använder både periodiska fullständiga skanningar och filsystemövervakning. Realtidsövervakning kan importera vanliga tillägg snabbt på lokala filsystem som stöds, medan en schemalagd fullständig skanning fortfarande kan fungera som ett säkerhetsnät med lägre frekvens.

Jellyfin har länge behandlat schemalagd skanning och realtidsövervakning som separata mekanismer. En projektfråga beskriver att realtidsövervakning kan upptäcka nya mediefiler, medan en schemalagd uppgift står för intervallbaserad upptäckt.

På tillförlitlig lokal lagring kan du testa realtidsövervakningen med en nyligen tillagd fil och minska frekvensen för den fullständiga skanningen först efter att filen har dykt upp korrekt. På NFS, SMB, rclone, sammanslagna filsystem och vissa containeranslutna sökvägar kan händelseleveransen vara ofullständig, så behåll en periodisk skanning vid en tidpunkt som passar lagringspolicyn.

Hitta uppgifter som läser mediefilernas innehåll i stället för bara katalognamn

Granska skanningsloggen efter medieavläsning, kontrollsummeavläsningar, extrahering av kapitel, analys av undertexter, generering av trickplay-filer, ljudstyrkeanalys och upprepade metadatauppdateringar. Att läsa kataloger kan orsaka en kort väckning, medan läsning av delar av varje fil kan hålla en hel diskarray aktiv i timmar.

Fallet med den upprepade skanningen rapporterade omfattande läsningar från varje mediefil under avläsningen, vilket förklarar varför jobbet gjorde mer än att kontrollera filnamn. En annan fråga visar att samma poster bearbetades på nytt vid varje skanning i stället för att nå ett stabilt tillstånd.

Åtgärda det första som förändras vid varje körning: en otillgänglig sökväg, ett behörighetsfel, en felaktigt formaterad sidofil, en instabil tidsstämpel, en duplicerad biblioteksrot eller en metadatapost som upprepade gånger tas bort och återskapas. Ett kortare intervall hjälper inte om varje skanning fortfarande behandlar samma innehåll som nytt.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Behåll metadata på SSD utan att anta att det stoppar alla väckningar

Placera programmets databas, cache, affischer och aktiva metadata på SSD när plattformen stöder det. Det minskar små slumpmässiga läsningar vid bläddring och håller rutinunderhåll av databasen borta från kapacitetsdiskarna.

Separering av lagring är ingen fullständig garanti. En regressionsrapport för Jellyfin dokumenterade väckningar av hårddiskar vid visning av biblioteksdetaljer även när cache och metadata låg på NVMe, vilket visar att servern fortfarande kan använda källmedier för vissa åtgärder.

Efter att appdata har flyttats bör du övervaka vilka källsökvägar som öppnas vid bläddring och skanningar. Behåll affischer, förhandsvisningar och databaser utanför mediediskarna där det är praktiskt, men behandla återstående åtkomst till källfiler som ett separat beteende att felsöka, inte som ett bevis på att flytten till SSD misslyckades.

Minska frekvens, omfattning och överlappande arbete

Kör fullständiga skanningar så ofta som biblioteket behöver dem och undvik att schemalägga dem samtidigt som säkerhetskopieringar, rensningar, generering av förhandsvisningar eller medieimporter. Skanna enskilda bibliotek eller mappar när plattformen tillåter riktade uppdateringar.

Inaktivera bred metadataersättning under rutinmässiga skanningar om metadata faktiskt inte behöver byggas om. En vanlig inkrementell skanning bör inte upprepade gånger generera kapitelbilder, trickplay-filer, affischer och identifiering av avsnitt för oförändrade mediefiler.

Använd ett förskjutet schema: importer först, en riktad biblioteksuppdatering efter importfönstret och tunga jobb för härledda filer på en separat dag eller endast vid behov. Det ger en förutsägbar väckningsperiod i stället för flera korta väckningar under natten.

Kontrollera att monteringar är tillgängliga innan medietjänsten startar

En saknad nätverks- eller poolmontering kan exponera en tom lokal katalog på den förväntade sökvägen. Medieservern kan skanna denna reservsökväg, ta bort objekt och sedan skanna allt igen när den riktiga resursen återkommer.

Avbrott i diskar eller monteringar kan få ett mediebibliotek att försvinna och tvinga fram en kostsam återuppbyggnad. En Jellyfin-fråga beskriver förlust av biblioteket efter att en montering kopplats från, vilket är det felbeteende som ett startberoende bör förhindra.

Konfigurera containern eller tjänsten så att den startar efter att nödvändiga monteringar är aktiva och innehåller data. Lägg till en kontroll av monteringen som letar efter en känd markör eller förväntad filsystemstyp och stoppa sedan skanningen när lagringssökvägen inte är tillgänglig, i stället för att behandla en tom katalog som ett giltigt bibliotek.

Verifiera stabilt viloläge under flera nätter

Efter varje ändring bör du notera när uppgifter startar och slutar, diskarnas strömtillstånd, läsvolym, de största loggposterna och om nyligen tillagda mediefiler fortfarande visas. En lugn natt räcker inte om den minskade skanningen bara körs med några dagars mellanrum.

ZimaSpace-guiden om val av HDD- och SSD-roller i en NAS ger sammanhang kring lagringslayouten och hur aktiva appdata kan hållas borta från vilande mediediskar.

Justeringen är lyckad när schemalagt underhåll sker under ett känt tidsfönster, oförändrade bibliotek inte längre utsätts för upprepat filnivåarbete, importer fortfarande upptäcks och hårddiskarna förblir vilande utanför uppspelning, verifierade skanningar, säkerhetskopieringar eller lagringsrelaterade hälsokontroller.