Felsökningsguide för USB-DAS vid frånkopplingar, strömförsörjning och UAS-fel

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.

Det säkra tillvägagångssättet är att fånga felsignaturen, ändra en variabel i taget och endast tillämpa den matchande åtgärden som en sekvens av observerbara kontrollpunkter, inte som ett enda kommando.

På en Linux-hemsserver med ett USB-anslutet DAS-kabinett är den praktiska risken att USB-DAS-diskar kopplas från, återställs eller försvinner under belastning. Dokumentera aktuell identitet och återställningspunkt, börja med den minst ingripande särskiljande åtgärden, tolka godkända och underkända resultat innan du ändrar en annan variabel och sluta när lagringen blir instabil eller när den enda återställningsbara kopian skulle exponeras. Arbetsflödet nedan avslutas först när den ursprungliga arbetsbelastningen lyckas eller när bevisningen når en eskaleringsgräns.

Fånga den exakta frånkopplingssignaturen

Stoppa skrivintensiva program och samla in journalctl -k -f eller dmesg -w medan du återskapar samma överföring. Dokumentera tidsstämplar, USB-topologi, bryggans leverantörs- och produkt-ID:n, förhandlad hastighet, enheternas serienummer, monteringsstatus och det första felet innan senare återställningsmeddelanden döljer den utlösande händelsen.

Ett löst Ask Ubuntu-fall visar ett typiskt fall med UAS-avbrott och frånkoppling där UAS-avbrottsmeddelanden och att enheten försvinner måste läsas tillsammans. Betrakta den signaturen som en avgränsad observation, inte som ett bevis på att varje frånkoppling beror på ett UAS-fel.

Sluta testa och skydda data om återställningar upprepas under skrivningar, filsystemet blir skrivskyddat, enheten klickar eller SMART- och enhetsfelräknare ökar. Kör inte filsystemreparation över en instabil USB-anslutning.

Skilj först på ström- och signalproblem

Återskapa arbetsbelastningen med det ursprungliga kabinettet och ändra sedan endast en sak: kabel, värdport, nätadapter eller strömförsörjd hubb där det är lämpligt. Håll disk, filsystem, arbetsbelastning och varaktighet konstanta. Ett bussdrivet kabinett med flera diskar som endast fallerar under uppvarvning eller samtidiga skrivningar tyder på ett strömproblem även om inaktiva läsningar fungerar felfritt.

Kontrollera om länken faller tillbaka till lägre hastighet, återställs när kontakten rörs eller endast fallerar via en frontpanelport eller förlängningskabel. Byt ut en misstänkt kabel mot en kort, certifierad kabel och undvik adaptrar under kontrolltestet. Om felet följer en viss port eller värd ska du hålla kabinettet utanför felsökningen tills styrenhet och strömhantering har testats.

Den här grenen klaras när den ursprungliga belastningen förblir ansluten under två kallstarter och en långvarig överföring efter en enda ändring av hårdvarusökvägen. Om varje kabel och port fallerar vid samma transaktionsmönster går du vidare till tester av bryggprotokoll och kabinett kontra disk.

Testa UAS som en kompatibilitetsgren, inte som den självklara boven

Bekräfta att enheten för närvarande använder uas och samla in dess exakta USB-ID. Först efter att du har återskapat UAS-specifika avbrott bör du testa samma enhet med en tillfällig, korrekt avgränsad usb-storage-anpassning eller på en värd som är känd för att använda bulk-only-sökvägen. Räkna med lägre ködjup eller prestanda under detta särskiljande test.

En felsökningstråd på Linux Mint rekommenderar att bevaka kärnloggar efter UAS-fel för att synliggöra UAS-relaterade fel medan enheten är ansluten. Använd jämförelsen för att avgöra om återställningarna försvinner under samma belastning; att bara se ordet uas i en logg bevisar inte orsakssamband.

Om bulk-only-transporten är stabil två gånger medan UAS upprepade gånger fallerar behåller du endast lösningen för det specifika leverantörs-/produkt-ID:t och kontrollerar alternativ för kabinettets fasta programvara eller byte. Om båda transporterna fallerar tar du bort anpassningen och fortsätter med isolering av ström, brygga, värme eller disk.

-15% OFF
Single board computer zimaboard2

Ta reda på om felen följer disken eller kabinettet

Placera den misstänkta disken i ett välfungerande kabinett eller en direkt SATA-sökväg och placera en välfungerande reservdisk i det misstänkta DAS-kabinettet. Kör samma icke-förstörande lästest innan någon skrivbelastning. Fel som följer disken pekar på dess lagringsmedium eller styrenhet; fel som stannar kvar hos DAS pekar på brygga, bakplan, kylning, kabel eller ström.

Den relaterade felsökningsguiden för ZimaSpace om felsökning mellan disk och kabinett beskriver beslutet vid byte mer detaljerat. Använd den efter transporttesterna så att ett bryggfel inte förväxlas med dåligt lagringsmedium och en felande disk inte döljs av upprepade återställningar av kabinettet.

Återställningen är godkänd när den ursprungliga arbetsbelastningen förblir stabil vid återanslutning, omstart och långvarig I/O, utan nya kärnåterställningar eller enhetsfel. Eskalera eller byt komponenten när felet konsekvent följer den; om resultaten fortfarande är blandade stoppar du skrivningar, avbildar kritiska data via den stabilaste sökvägen och sparar loggarna för hårdvarusupport.

Support och tips

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.