Waarom wordt een externe HDD-behuizing alleen tijdens verificatielezingen ontkoppeld?
Een externe HDD-behuizing kan tijdens de verificatie de verbinding verbreken, omdat langdurige leesbewerkingen marginale problemen met de voeding, USB-transportlaag, bridgechip, warmte, kabel of schijf blootleggen.
Bij normaal browsen worden slechts kleine gebieden gelezen, waardoor de behuizing mogelijk nooit lang genoeg wordt belast om een zwakke adapter, instabiele bridgechip, beschadigde kabel, oververhitte controller of onleesbare schijfregio aan het licht te brengen. Verificatiewerkzaamheden lezen sequentieel en langdurig en proberen vaak mislukte sectoren opnieuw, waardoor precies de belasting ontstaat die een instabiel pad laat resetten. Diagnoseer het USB-transport en de schijf afzonderlijk voordat u ervan uitgaat dat een van beide onderdelen moet worden vervangen.
Bevestig of het apparaat wordt gereset of alleen het bestandssysteem wordt ontkoppeld
Noteer de eerste systeemloggebeurtenis, de USB-apparaatidentiteit, de naam van het blokapparaat, de aankoppelstatus en de verificatie-offset wanneer de fout optreedt. Bepaal of de behuizing uit de USB-enumeratie verdwijnt, de schijf aanwezig blijft maar I/O-fouten meldt, of het bestandssysteem na fouten wordt ontkoppeld.
De documentatie over energiebeheer voor Linux-USB maakt onderscheid tussen wijzigingen in het apparaatvermogen en gedrag op een hoger niveau, zoals dat van het bestandssysteem. Het USB-energiemodel van de kernel helpt om een USB-onderbreking of -reset te onderscheiden van een reactie van het bestandssysteem op mislukte opslag-I/O.
Als de behuizing uit de USB-enumeratie verdwijnt, richt u dan eerst op voeding, kabel, firmware van de bridgechip, hostcontroller en opschorting. Als de behuizing aanwezig blijft maar leesfouten meldt, bewaar dan het foutadres en onderzoek de schijf of de vertaling door de bridgechip.
Test de stroomvoorziening onder langdurige leesbelasting
Gebruik de juiste voedingsadapter voor de behuizing, sluit deze rechtstreeks aan op de host en verwijder niet-gevoede hubs of verlengkabels aan de voorkant. Vergelijk het gedrag tijdens het opstarten, in rust en tijdens de verificatie.
De probleemoplossingsrichtlijnen van Seagate voor externe schijven adviseren eerst voeding, een directe USB-verbinding, kabels en alternatieve poorten te controleren voordat u ervan uitgaat dat de schijf defect is, omdat langdurige activiteit een marginale verbinding aan het licht kan brengen die bij licht gebruik blijft werken.
Een behuizing met voeding die alleen onder belasting de verbinding verbreekt, kan nog steeds een te lichte of defecte adapter hebben. Gebruik geen andere voeding tenzij spanning, polariteit, connector en stroomsterkte overeenkomen met de vereisten van de behuizing.
Schakel USB-selectieve onderbreking uit voor één gecontroleerde test
Noteer het USB-energiebeleid van het besturingssysteem en of de behuizing vóór het begin van de verificatie in een ruststand komt. Wijzig indien mogelijk alleen het betreffende apparaat of testsysteem.
Microsoft beschrijft USB-selectieve onderbreking als een energiebeheerfunctie per apparaat. Deze functie bespaart energie, maar is ook een geldige onderscheidende test wanneer één opslagpad rond het onderbreken of hervatten uitvalt.
Als de behuizing stabiel wordt wanneer onderbreking is uitgeschakeld, werk dan eerst de chipset-, USB- en behuizingsfirmware bij voordat u energiebesparing permanent uitgeschakeld laat. Een geslaagde test wijst op een interactie met de energiestand, maar identificeert niet noodzakelijkerwijs het uiteindelijke defecte onderdeel.
Vergelijk UAS met bulk-only USB-transport
Controleer of de behuizing USB Attached SCSI of het oudere bulk-only transport gebruikt. Noteer de identiteit van de bridgechip, het stuurprogramma, de wachtrijdiepte en de fouten voordat u van modus verandert.
De lsusb-naslaginformatie van Debian helpt bij het identificeren van de bridgechip en de actieve USB-interface. Dat is nodig voordat u een apparaatspecifieke transportoplossing toepast.
Het testen van de bulk-only modus kan een probleem met UAS of wachtrijverwerking aan het licht brengen, maar vermindert ook de prestaties en parallelle uitvoering van opdrachten. Gebruik dit als een gecontroleerde vergelijking en niet als universele oplossing voor elke behuizing.
Voer gezondheidstests van de schijf uit zonder belasting door het bestandssysteem
Lees SMART-gegevens uit via de behuizing als de bridgechip doorgifte ondersteunt. Noteer wachtende sectoren, onherstelbare fouten, CRC-fouten van de interface, temperatuur, time-outs van opdrachten en de geschiedenis van zelftests.
De Debian-handleiding voor smartctl legt uit dat SMART-zelftests en foutenlogboeken kunnen helpen om mediafouten te onderscheiden van resets van het USB-transport, wanneer de behuizing de vereiste opdrachten doorgeeft aan de schijf.
Een geslaagde korte test sluit niet uit dat een schijf tijdens het lezen van het volledige oppervlak faalt. Gebruik een lange test of alleen-lezen scan uitsluitend wanneer er een back-up van de gegevens is en de schijf geen snel toenemende fouten vertoont.
Controleer de kwaliteit van de kabel, de hostpoort en de USB-topologie
Vervang de datakabel door een korte, goed werkende kabel en sluit de behuizing aan op een andere poort aan de achterzijde van het moederbord. Vermijd adapters en hubs tijdens de test.
USB-IF legt uit dat het USB-voedingspad uit meerdere onderdelen bestaat. Een connector die werkt voor korte metagegevenslezingen kan dus alsnog uitvallen wanneer de behuizing en schijf langdurig zwaarder worden belast.
Als het probleem een bepaalde kabel of poort volgt, vervang dat onderdeel dan. Als het probleem de behuizing naar verschillende hosts volgt, richt u dan op de bridgechip, voeding, koeling of de schijf zelf.
Breng herhaalbare foutlocaties in kaart en voorkom gegevensverlies
Herhaal de verificatie alleen lang genoeg om vast te stellen of de verbinding wordt verbroken bij hetzelfde logische blokbereik, na dezelfde verstreken tijd of bij dezelfde temperatuur. Deze patronen helpen om beschadigde media te onderscheiden van instabiliteit door warmte of transport.
Het ZimaSpace-artikel over verbindingen die met externe back-upschijven worden verbroken biedt een aanvullende vergelijking tussen fouten tijdens langdurige overdrachten en fouten in de opslagmedia.
Stop met testen en kopieer eerst herstelbare gegevens wanneer leesfouten toenemen, de schijf herhaaldelijk in hetzelfde bereik reset, de SMART-gezondheid verslechtert of de behuizing oververhit raakt. Het probleem is pas opgelost wanneer een volledige leesverificatie op een stabiel pad is voltooid zonder USB-resets, I/O-fouten of toenemende gezondheidswaarschuwingen.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Kan Plex een GPU delen met een andere Docker-container?
Plex en een andere container kunnen vaak dezelfde GPU gebruiken, maar je moet de driverondersteuning, apparaattoewijzing, belasting van de video-engine, het geheugengebruik en het...
Hoe je kunt bepalen of een Plex-fout door de client of de server wordt veroorzaakt
Reproduceer hetzelfde item op een andere client, vergelijk het sessiepad en verzamel pas serverbewijs nadat de scope heeft uitgewezen waar de fout daadwerkelijk zit.
Plex-cache en tijdelijke opslag voor transcodering configureren
Bescherm de permanente Plex-status door tijdelijke transcodebestanden op geschikte lokale opslag te plaatsen en controleer vervolgens het opruimen, de beschikbare ruimte en het gedrag...
