Varför kopplas ett externt hårddiskkabinett från endast under verifieringsläsningar?
Ett externt HDD-kabinett kan kopplas från under verifiering eftersom långvariga läsningar blottlägger marginell strömförsörjning, USB-transport, brygga, värme, kabel- eller diskarfel.
Vid vanlig bläddring läses bara små områden, vilket kanske aldrig belastar kabinettet tillräckligt länge för att avslöja en svag nätadapter, ett instabilt bryggchip, en skadad kabel, en överhettad styrenhet eller ett oläsbart disksegment. Verifieringsläsningar är sekventiella, långvariga och försöker ofta läsa om misslyckade sektorer, vilket skapar exakt den belastning som får en instabil anslutningsväg att återställas. Diagnostisera USB-transporten och disken separat innan du antar att någon av komponenterna måste bytas ut.
Bekräfta om enheten återställs eller om filsystemet bara avmonteras
Notera den första händelsen i systemloggen, USB-enhetens identitet, blockenhetens namn, monteringsstatus och verifieringspositionen när felet inträffar. Ta reda på om kabinettet försvinner från USB, om disken finns kvar men rapporterar I/O-fel eller om filsystemet avmonteras efter felen.
Linux-dokumentationen om USB-strömhantering skiljer mellan förändringar i enhetens strömstatus och beteenden på högre nivå i filsystemet. Kärnans modell för USB-strömhantering hjälper dig att skilja en USB-relaterad avstängning eller återställning från en filsystemsreaktion på misslyckad lagrings-I/O.
Om kabinettet försvinner från USB-enumereringen bör du först fokusera på strömförsörjning, kabel, bryggans fasta programvara, värdstyrenheten och avstängning. Om det fortfarande är anslutet men rapporterar läsfel bör du bevara den felande adressen och undersöka disken eller bryggans översättning.
Testa strömförsörjningen under långvarig läsbelastning
Använd kabinettets korrekta nätadapter, anslut den direkt till värdenheten och ta bort strömlösa hubbar eller förlängningar via frontpanelen. Jämför beteendet vid uppstart, tomgång och verifiering.
Seagates felsökningsguide för externa enheter rekommenderar att du kontrollerar strömförsörjning, direkt USB-anslutning, kablar och alternativa portar innan du betraktar disken som trasig, eftersom långvarig aktivitet kan avslöja en marginell anslutning som klarar lätt användning.
Ett strömförsörjt kabinett som kopplas från endast under belastning kan fortfarande ha en underdimensionerad eller defekt nätadapter. Byt inte nätaggregat om inte spänning, polaritet, kontakt och strömstyrka motsvarar kabinettets krav.
Inaktivera USB-selektiv avstängning i ett kontrollerat test
Notera operativsystemets USB-strömprofil och om kabinettet går in i viloläge innan verifieringen börjar. Ändra endast den berörda enheten eller testsystemet när det är möjligt.
Microsoft beskriver USB-selektiv avstängning som en strömfunktion per enhet. Den är användbar för energibesparing, men också en giltig skiljemetod när en lagringsanslutning fallerar kring avstängning eller återupptagning.
Om kabinettet blir stabilt när avstängning är inaktiverad bör du fortsätta med att uppdatera kretsuppsättningens, USB-enhetens och kabinettets fasta programvara innan du permanent lämnar energisparfunktionen inaktiverad. Ett lyckat test identifierar en interaktion med strömtillståndet, inte nödvändigtvis den slutliga felande komponenten.
Jämför UAS- och bulk-only-USB-transport
Kontrollera om kabinettet använder USB Attached SCSI eller den äldre bulk-only-transporten. Notera bryggchipets identitet, drivrutin, ködjup och fel innan du ändrar läge.
Debians lsusb-referens stöder identifiering av bryggan och det aktiva USB-gränssnittet, vilket krävs innan du tillämpar en enhetsspecifik transportlösning.
Test av bulk-only-läge kan avslöja ett UAS- eller köhanteringsproblem, men det minskar också prestandan och möjligheten att behandla kommandon parallellt. Använd det som en kontrollerad jämförelse, inte som en universallösning för alla kabinett.
Kör hälsotester av disken utan filsystemets arbetsbelastning
Läs SMART-data genom kabinettet om bryggan stöder genomkoppling. Notera väntande sektorer, okorrigerbara fel, CRC-fel i gränssnittet, temperatur, kommandotimeoutar och historik över självtester.
Debians smartctl-handbok förklarar att SMART-självtester och felloggar kan hjälpa till att skilja mediefel från USB-transportåterställningar när kabinettet vidarebefordrar de nödvändiga kommandona till disken.
Ett felfritt kort test friar inte en disk som fallerar vid läsning av hela ytan. Använd ett långt test eller en skrivskyddad genomsökning endast när data är säkerhetskopierad och disken inte uppvisar snabbt förvärrade fel.
Kontrollera kabelkvalitet, värdport och USB-topologi
Byt datakabeln mot en kort, beprövat fungerande kabel och flytta kabinettet till en annan port på moderkortets baksida. Undvik adaptrar och hubbar under testet.
USB-IF förklarar att USB-strömvägen innebär att en kontakt som fungerar vid korta metadataavläsningar ändå kan fallera när kabinettet och disken arbetar mer intensivt under längre tid.
Om problemet följer en viss kabel eller port bör du ta den komponenten ur bruk. Om problemet följer kabinettet mellan olika värdenheter bör du fokusera på dess brygga, strömförsörjning, kylning eller själva disken.
Kartlägg återkommande felpositioner och stoppa innan data går förlorad
Upprepa verifieringen endast så långt att du kan avgöra om frånkopplingen sker inom samma logiska blockintervall, efter samma förflutna tid eller vid samma temperatur. Dessa mönster skiljer medieskador från värme- eller transportinstabilitet.
ZimaSpaces artikel om frånkopplingar av externa säkerhetskopieringsdiskar ger en närliggande jämförelse mellan fel vid långvariga överföringar och fel i lagringsmediet.
Sluta testa och kopiera först all data som går att rädda när läsfelen ökar, disken upprepade gånger återställs vid samma intervall, SMART-hälsan försämras eller kabinettet överhettas. Problemet är löst först när en fullständig läsverifiering slutförs via en stabil anslutning utan USB-återställningar, I/O-fel eller ökande hälsovarningar.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
