Seagate Expansion Desktop matar ut sig själv

Permalänk
Medlem

Seagate Expansion Desktop matar ut sig själv

Jag har en NUC som jag använder som mediaserver över nätverket hemma. Till den så har jag kopplat en hårddisk av modellen Seagate Expansion Desktop på 16TB via USB där jag lagrar allt. Jag använder Ubuntu Server på NUC:en och formaterat disken i exFAT-formatet. Tanken är att NUC:en ska stå på 24/7, men problemet jag nämner nedan förhindrar detta mål.

Allting fungerar strålande, förutom en väldigt störig grej där disken med jämna mellanrum matar ut sig själv, tror jag. Jag märker detta genom att filer helt plötsligt blir onåbara, och när jag via SSH tittar till /media där disken ska vara mountad, så ser jag att den inte längre är mountad, dvs att mappen för disken är där men är tom. Jag måste då reboota NUC:en för att disken ska mounta igen.

Tiden mellan då disken matar ut sig varierar väldigt mycket. Ibland kan den fungera utan problem i veckor, ibland kan jag behöva starta om NUC:en efter en eller två dagar.

Ibland kan enstaka mappar och filer ändå ligga kvar när jag tittar i mappen för disken, trots att disken inte är mountad. I det scenariot måste jag rm -rf mappen för disken och reboota NUC:en för att den ska mounta korrekt vid uppstart. Då kan det ibland hända att vissa filer är borta.

Jag försöker förstå vad det är som orsakar detta. Jag har fått upplysning om att det kan vara att disken automatiskt hamnar i viloläge och att den då matar ut sig själv. Jag har dock inte hittat någon metod för att i sådana fall avaktivera den funktionen.

Är det någon som vet vad det annars skulle kunna bero på? Är modellen av disk inte menad att användas för det jag vill använda den till?

Permalänk
Medlem

Går att inaktivera genom att tejpa över en pin på SATA-anslutningen om du inte hittar nåt sätt att göra det mjukvarumässigt.

Visa signatur

HTPC: Silverstone Sugo SG05W Vit, Asus H110I-Plus, G4560, Corsair Vengeance LPX 2133 MHz 2x4GB, Samsung 870 EVO 500GB, Toshiba N300 2x10TB, MSI GeForce GT 1030 Passive OC 2GB, (& 16 enkortsdatorer med div användningsområden). Har ett "par" andra stationära datorer åxå. LG OLED 65CX. Shield 2019 Pro.

Permalänk
Medlem

Okej, intressant! Finns det några instruktioner för hur man gör någonstans?

Permalänk
Medlem

vad säger "dmesg -T" efter att det hänt?

Permalänk
Medlem
Skrivet av toge:

Okej, intressant! Finns det några instruktioner för hur man gör någonstans?

Tredje från vänster.

Visa signatur

HTPC: Silverstone Sugo SG05W Vit, Asus H110I-Plus, G4560, Corsair Vengeance LPX 2133 MHz 2x4GB, Samsung 870 EVO 500GB, Toshiba N300 2x10TB, MSI GeForce GT 1030 Passive OC 2GB, (& 16 enkortsdatorer med div användningsområden). Har ett "par" andra stationära datorer åxå. LG OLED 65CX. Shield 2019 Pro.

Permalänk
Medlem
Skrivet av MatteN:

Okej! Värt att testa! Är det eltejp som gäller då?

Permalänk
Medlem
Skrivet av varget:

vad säger "dmesg -T" efter att det hänt?

Är fortfarande rätt färsk med Linux, men ska testa! Är det någon form av logg som visas då?

Permalänk
Medlem
Skrivet av toge:

Är fortfarande rätt färsk med Linux, men ska testa! Är det någon form av logg som visas då?

Ja precis, det är en ganska generisk logg du får som troligen kommer ge ledtrådar om var du kan fortsätta leta.
Man ska väl inte copy pasta random saker folk postar på internet så jag länkar lite om det https://en.wikipedia.org/wiki/Dmesg

-T anger tid i mänsklig form och inte sekunder sen boot.

Permalänk
Medlem
Skrivet av toge:

Okej! Värt att testa! Är det eltejp som gäller då?

Bäst så, även om det är svagström.

Visa signatur

HTPC: Silverstone Sugo SG05W Vit, Asus H110I-Plus, G4560, Corsair Vengeance LPX 2133 MHz 2x4GB, Samsung 870 EVO 500GB, Toshiba N300 2x10TB, MSI GeForce GT 1030 Passive OC 2GB, (& 16 enkortsdatorer med div användningsområden). Har ett "par" andra stationära datorer åxå. LG OLED 65CX. Shield 2019 Pro.

Permalänk
Medlem
Skrivet av MatteN:

Bäst så, även om det är svagström.

Vilka potentiella nackdelar får man räkna med när man tejpar pinnen? Kortare livslängd?

Permalänk
Medlem
Skrivet av varget:

Ja precis, det är en ganska generisk logg du får som troligen kommer ge ledtrådar om var du kan fortsätta leta.
Man ska väl inte copy pasta random saker folk postar på internet så jag länkar lite om det https://en.wikipedia.org/wiki/Dmesg

-T anger tid i mänsklig form och inte sekunder sen boot.

Tack, ska kolla närmare på det. Det dumma är att det ofta händer utan att jag märker något, så jag kanske upptäcker först en eller två dagar efter att disken har matat ut. Men det kanske ändå är en del av loggen då givet att så mycket annat inte händer på NUC:en då den är rätt beroende av disken för sin aktivitet.

Permalänk
Medlem
Skrivet av toge:

Tack, ska kolla närmare på det. Det dumma är att det ofta händer utan att jag märker något, så jag kanske upptäcker först en eller två dagar efter att disken har matat ut. Men det kanske ändå är en del av loggen då givet att så mycket annat inte händer på NUC:en då den är rätt beroende av disken för sin aktivitet.

Ja du kan köra det dagar efter, så länge du inte bootat om. Då får man leta i /var/log/dmesg*

Permalänk
Medlem
Skrivet av toge:

Vilka potentiella nackdelar får man räkna med när man tejpar pinnen? Kortare livslängd?

Får väl ställas mot att tappa kontakten med den och behöva starta om. Men troligen försumbart.

Visa signatur

HTPC: Silverstone Sugo SG05W Vit, Asus H110I-Plus, G4560, Corsair Vengeance LPX 2133 MHz 2x4GB, Samsung 870 EVO 500GB, Toshiba N300 2x10TB, MSI GeForce GT 1030 Passive OC 2GB, (& 16 enkortsdatorer med div användningsområden). Har ett "par" andra stationära datorer åxå. LG OLED 65CX. Shield 2019 Pro.

Permalänk
Medlem
Skrivet av varget:

Ja du kan köra det dagar efter, så länge du inte bootat om. Då får man leta i /var/log/dmesg*

Jag har formaterat den interna disken på NUC:en för att börja om på ny kula, dock är externa fortfarande så som den var tidigare. Har kört den sedan igår och såg precis att disken inte är tillgänglig, dock är det ett nytt felmeddelande i terminalen som jag inte fått tidigare. Har också testat att tejpa över pin 3 med eltejp som MatteN tipsade om för att se om det gör någon skillnad.

När jag försöker köra 'ls' när jag är i mappen för disken så får jag följande:
"ls: reading directory '.': Input/output error"

Detta är som sagt inget som jag fått tidigare. Jag har då antingen möts av en tom mapp, så att inget listats, eller att mappen innehåller enstaka filer och mappar.

Jag testade då att köra "dmesg -T" som du tipsade om. Får en massa listat i loggen så klart, men längst ner står följande:
"[Sun Jan 30 20:21:04 2022] [EXFAT] statfs on device that is ejected"

Finns det något mer i loggen som jag bör titta efter?

Kan det vara formatet, i detta fall exFAT, som orsakar problemet? Eller bör det inte spela någon roll?

Permalänk
Medlem

Hittade också den här raden en bit upp i loggen:
"[Sun Jan 30 20:20:53 2022] [EXFAT] No bh, device seems wrong or to be ejected."

Permalänk
Medlem

du klipper för hårt - behövs fler rader kring dessa fel - dvs. rader som det står 'sda' sdb' och allt som handlar om SCSI-enheter (sata-diskar och USB-diskar behandlas som SCSI-diskar rent logiskt) även meddelande som har med USB om det är externa USB-disken som krånglar.

typ de sista 4 helskärmssidorna uppåt från när disken ejektas.

En del SATA/USB-kontroller för externa diskar uppvisar inte den önskade driftsäkerheten som man önskar för saker som skall vara igång långa tider och de flesta USB/SATA-chip från jmicron, asmedia mfl. har var och en långa listor av olika buggar som utvecklarna har slagits med och upptäckt på vägen, men de har inte hittat alla...

En sak att kolla är att strömförsörjningen till diskarna verkligen är stabil och att det inte är en massa hyss där, samma sak att man inte håller på med att starta upp och stänga av diskarna hela tiden och dessvärre envisas en del USB/SATA-chip att stänga av spindeln på själva disken när det har varit för lång tids inaktivitet och att det inte går att ställa om med några kommandon - man får göra ett script som läser på disken på slumpat ställe var minut eller så (slumpat för att inte disk-cachen skall ge data istället för disken själv, då när det hämtas från diskcachen så accessas inte disken.) - alternativt fyller på en loggfil på disken med några tecken per minut eller lägger in en ny filtid på en 0-bytes-fil då data och metadatat alltid synkas mot disken fysiskt med skrivning inom någon minut, oftast inom 30 sekunder.

slutligen - måste du köra just exFAT? - det är inte lika välbeprövat filsystem som ext4 eller tom. BTRFS när det gäller återhämtning av störningar/avbrott - att prova annan filsystem kan ge en ide om det är kopplat till val av filsystem eller inte, även om det för närvarade låter som mer lågnivå, under filsystemsnivå när det gäller fel, men som du själv redan nämnt - kan ta tid att prova ut om det är veckor mellan felen.

Permalänk
Medlem
Skrivet av toge:

Jag testade då att köra "dmesg -T" som du tipsade om. Får en massa listat i loggen så klart, men längst ner står följande:
"[Sun Jan 30 20:21:04 2022] [EXFAT] statfs on device that is ejected"

Skrivet av toge:

Hittade också den här raden en bit upp i loggen:
"[Sun Jan 30 20:20:53 2022] [EXFAT] No bh, device seems wrong or to be ejected."

Skrivet av xxargs:

du klipper för hårt - behövs fler rader kring dessa fel

^^^This

Om du vill ha hjälp så ha med allt. Eller iaf det som är tidsmässigt nära på några timmar.

Permalänk
Medlem
Skrivet av xxargs:

du klipper för hårt - behövs fler rader kring dessa fel - dvs. rader som det står 'sda' sdb' och allt som handlar om SCSI-enheter (sata-diskar och USB-diskar behandlas som SCSI-diskar rent logiskt) även meddelande som har med USB om det är externa USB-disken som krånglar.

typ de sista 4 helskärmssidorna uppåt från när disken ejektas.

En del SATA/USB-kontroller för externa diskar uppvisar inte den önskade driftsäkerheten som man önskar för saker som skall vara igång långa tider och de flesta USB/SATA-chip från jmicron, asmedia mfl. har var och en långa listor av olika buggar som utvecklarna har slagits med och upptäckt på vägen, men de har inte hittat alla...

En sak att kolla är att strömförsörjningen till diskarna verkligen är stabil och att det inte är en massa hyss där, samma sak att man inte håller på med att starta upp och stänga av diskarna hela tiden och dessvärre envisas en del USB/SATA-chip att stänga av spindeln på själva disken när det har varit för lång tids inaktivitet och att det inte går att ställa om med några kommandon - man får göra ett script som läser på disken på slumpat ställe var minut eller så (slumpat för att inte disk-cachen skall ge data istället för disken själv, då när det hämtas från diskcachen så accessas inte disken.) - alternativt fyller på en loggfil på disken med några tecken per minut eller lägger in en ny filtid på en 0-bytes-fil då data och metadatat alltid synkas mot disken fysiskt med skrivning inom någon minut, oftast inom 30 sekunder.

slutligen - måste du köra just exFAT? - det är inte lika välbeprövat filsystem som ext4 eller tom. BTRFS när det gäller återhämtning av störningar/avbrott - att prova annan filsystem kan ge en ide om det är kopplat till val av filsystem eller inte, även om det för närvarade låter som mer lågnivå, under filsystemsnivå när det gäller fel, men som du själv redan nämnt - kan ta tid att prova ut om det är veckor mellan felen.

Skrivet av varget:

^^^This

Om du vill ha hjälp så ha med allt. Eller iaf det som är tidsmässigt nära på några timmar.

Okej, idag hände det igen och jag har nu kopierat loggen från ungefär då jag tittade till datorn först runt kl 8 imorse fram till nu. Finns på https://pastebin.com/ykYEynmZ

Runt 10:43:21 verkar något I/O-error hända som gör att den matar ut sig.

Skrivet av xxargs:

slutligen - måste du köra just exFAT? - det är inte lika välbeprövat filsystem som ext4 eller tom. BTRFS när det gäller återhämtning av störningar/avbrott - att prova annan filsystem kan ge en ide om det är kopplat till val av filsystem eller inte, även om det för närvarade låter som mer lågnivå, under filsystemsnivå när det gäller fel, men som du själv redan nämnt - kan ta tid att prova ut om det är veckor mellan felen.

Jag är helt ärligt väldigt novis när det kommer till hårddiskar och format, men jag fick tipset att köra exFAT just för att jag använder både Windows och macOS, men det kanske finns liknande format som lirar bra med båda som är är bättre/mer beprövade?

Permalänk
Medlem
Skrivet av toge:

Okej, idag hände det igen och jag har nu kopierat loggen från ungefär då jag tittade till datorn först runt kl 8 imorse fram till nu. Finns på https://pastebin.com/ykYEynmZ

Runt 10:43:21 verkar något I/O-error hända som gör att den matar ut sig.

Jag är helt ärligt väldigt novis när det kommer till hårddiskar och format, men jag fick tipset att köra exFAT just för att jag använder både Windows och macOS, men det kanske finns liknande format som lirar bra med båda som är är bättre/mer beprövade?

[Tue Feb 1 10:43:21 2022] usb 2-2: USB disconnect, device number 2

Testa annan kabel, annan usb port, uppdatera UEFI.

Om du har möjlighet testa disken i en annan dator.

Permalänk
Medlem

Vet inte om det är ett problem längre men du kan testa att lägga till uas (https://en.wikipedia.org/wiki/USB_Attached_SCSI) i blacklist med

sudo sh -c 'echo blacklist uas >> /etc/modprobe.d/blacklist.conf'

och starta om

*Igen lista inte blid på vad folk skriver på internet, speciellt inte när sudo är inblandat.

Permalänk
Medlem
Skrivet av varget:

[Tue Feb 1 10:43:21 2022] usb 2-2: USB disconnect, device number 2

Testa annan kabel, annan usb port, uppdatera UEFI.

Om du har möjlighet testa disken i en annan dator.

Skrivet av varget:

Vet inte om det är ett problem längre men du kan testa att lägga till uas (https://en.wikipedia.org/wiki/USB_Attached_SCSI) i blacklist med

sudo sh -c 'echo blacklist uas >> /etc/modprobe.d/blacklist.conf'

och starta om

*Igen lista inte blid på vad folk skriver på internet, speciellt inte när sudo är inblandat.

Tack! Lite följdfrågor:

• Hur uppdaterar jag UEFI?
• Av vilken anledning vill man blacklista UAS?

Permalänk
Medlem
Skrivet av toge:

Tack! Lite följdfrågor:

• Hur uppdaterar jag UEFI?
• Av vilken anledning vill man blacklista UAS?

https://www.intel.com/content/www/us/en/support/articles/0000...

Uas kunde iaf tidigare vara instabilt. Vet inte om detta är ett stort problem lägre. Värt att testa helt enkelt. Dock kommer du få högre CPU last och/eller lägre disk prestanda. Men eftersom du kör via nätverket kanske det inte spelar roll

Permalänk
Medlem

Scrolla igenom loggen igen, antar att du har en nvme disk i nucen som boot/OS. Om det inte är sant säg till.
Såg även att disken kopplas in igen som sdb (från tidigare sda). Kolla så att du använder uuid (https://help.ubuntu.com/community/UsingUUID) i /etc/fstab

Permalänk
Medlem

Rad 69 så hände det något - förmodligen var det den externa disken som fimpade USB-kopplingen helt av sig själv och allt man ser därefter är följdfel med öppnade filer etc. som lämnades vind för våg.

Eventuellt rad 56 kan indikera disken inte svarar så snabbt som förväntat - den typen av att minska sampeltakten i steg för steg ser man när diskar börja bli tröga att svara som tex. SSD som slutar att svara när deras TRIM-tabell blir igensotad med nystan av referenser med väldigt många sprida sektorskrivningar som tex. med bcache när man gör deduplicering av diskar med 'bees' på BTRFS filsystem - det är alltså firmwarebuggar i själva de äldre MLC-SSD:erna av flertal olika märken sonika stannar och blir utkickat för att de inte svarar alls till slut.

---

Att disken dyker upp igen, nu som helt annan PCIe-namn och därmed annan SCSI-enhets-namn (och blev döpt till /dev/sdb - istället för innan /dev/sda) är för OS:t en ny disk - har inget med den gamla disken att göra och dess dinglande sektorer som väntar på att skrivas i dess ögon

- felet är egentligen på BIOS och moderkortsnivå att den tappade den gamla disken och när den kom tillbaka igen fick ett nytt PCIe-namn av moderkortets PCIe-systemet (Plug and Play-systemet) istället för att återanvända den gamla PCIe-namnet och därmed fick disken en ny SCSI-namn och med det en ny enhetsnamn (/dev/sdb) - förmodligen att moderkortet inte uppfattade att den gamla kopplingen till USB-disken är stäng i alla led, och därför upplevde den återkommande disken som en helt ny disk - och därför blir inte disken re-attachad med filsystemet som hänger och dinglar med sina köade skrivoperationer då ur OS:s synpunkt är två helt olika diskar.

USB/SATA-chipen som används i många av Seagates diskcabinet (och är typiskt jmicron eller motsvarande-chipfamilj i botten) är ökända för att vara buggiga att man periodvis gjorde disable av UAS-stödet redan från början då utvecklarna bara inte orkar och hinner med att lirka ut alla fel som det bara hela tiden regnar in från dessa chiptillverkare med helt uppenbart ingen egen QC längre för sin firmware innan de börja skeppa ut chip i massor. Har man stabilitetsbekymmer är det bra att stänga av UAS-stödet och se om det klarar sig bättre.

Men i det här fallet verkade det vara kabinettet själv som la på luren utan att OS vad med på det och man kanske skall titta på andra saker som USB-kablar (dom medföljande är ingen garanti att de är bra - prova annan) - att strömförsörjningen är OK och inte har korta avbrott (går det via UPS ??) - kanske en annan 12-Volts vägvårta för externa USB-diskar också...

Permalänk
Medlem

Stort tack för alla hjälpsamma svar!

Har svartlistat Uas och disken har faktiskt gått på nu i ett par dagar. Återstår att se om det händer igen, testar i sådana fall era andra tips och återkommer.