Ubuntu Suomen keskustelualueet
Ubuntun käyttö => Ubuntu tietokoneissa => Aiheen aloitti: Snufkin - 18.08.25 - klo:13.22
-
Tällainen ongelma: Varakopionin läppäriltä n. 20G dataa, joka Linuxin omalla kryptauksella suojattua. Kopiointi toimii aluksi ok (500M-1G) mutta sitten hidastuu merkittävästi. Kopiointi 1G paloissa tuntuu toimivan paremmin. Source-levy on SSD ja mikään prosessi ei kuluttanut juurikaan laskentatehoa. Target on ulkoinen, uudehko 1T kovo, jossa ei ole kryptausta.
Mistä moinen voisi johtua? Onko sen kryptauksen aiheuttamaa?
-
Millä USB-standardin versiolla ulkoinen levy kytkeytyy koneeseen? Vanha USB 2.0 siirtää käytännössä vain n. 30 megatavua sekunnissa, eli 1 Gt siirtyy puolessa minuutissa.
En usko, että salaus hidastaisi siirtoa näin paljon. Se tuntuisi kaikessa järjestelmän ja sovellusten käytössä.
-
Millä USB-standardin versiolla ulkoinen levy kytkeytyy koneeseen? Vanha USB 2.0 siirtää käytännössä vain n. 30 megatavua sekunnissa, eli 1 Gt siirtyy puolessa minuutissa.
Luulisin, että usb 3.0. Ainakin kernel sitä tulee ja spekseistä löytyy (Lenovo X240)
Ja tuo alku menee aika vauhdikkaasti, mutta sitten hyytyy noin 0,5-1 G kohdalla.
-
Voisiko se vaikuttaa, että nyt kopiotu data ei ole aktiivisessa käytössä? Eli maannut levyllä kauan koskemattomana.
-
Kopionti meni siis suunnilleen niin, että esim. 4G erästä 1G vei muutaman minuutin (en seurannut tarkkaan) ja sitten kokonaisuus venähti yli tunnin mittaiseksi.
-
Ulkoisten kovojen ohjaimet ei ole useinkaan kovin nopeita. Jos kopioitava materiaali sisältää paljon pieniä tiedostoja, niin olen huomannut, että kopiointi hidastuu merkittävästi.
-
Ulkoisten kovojen ohjaimet ei ole useinkaan kovin nopeita. Jos kopioitava materiaali sisältää paljon pieniä tiedostoja, niin olen huomannut, että kopiointi hidastuu merkittävästi.
Hyytyi valokuvien kohdalla, jotka luokaa 1-5M
-
Nämä tuoreimmat SMR (shingled magnetic recording) USB-kiintolevyt on todella hitaita sen jälkeen kun välimuisti täyttyy (128-512Mt) ja valitettavasti käytännössä kaikki 2,5" USB-asemat on nykyään niitä.Jos mahdollista, niin kannattaa pysyä perinteisissä asemissa CMR (Conventional magnetic recording) ja näissä välimuisti yleensä reilusti alle 128Mt.
Karrikoidusti voi sanoa, että nämä uudet SMR-asemat tekee tavallaan jatkuvaa defragmentointia kun tiedostoja kopioidaan.
Tuossa viestiketju omiin kokemuksiin kryptatusta ulkoisesta 2,5" USB-asemasta
https://forum.ubuntu-fi.org/index.php?topic=59323.msg451145#msg451145
"Sain kopion tehtyä Veracrypt kontaineriin viimein. 2,7 teraa ja kirjoitusaika n.38h ja tuokin vielä hiukan optimistinen"
-
Tuossa viestiketju omiin kokemuksiin kryptatusta ulkoisesta 2,5" USB-asemasta
Tässä niin päin että:
SSD (kryptattu osio) -> purku -> siirto Usb 3.0(?) -> tallennus HDD (ei kryptausta, 1T Seagate)
-
Kopionti meni siis suunnilleen niin, että esim. 4G erästä 1G vei muutaman minuutin (en seurannut tarkkaan) ja sitten kokonaisuus venähti yli tunnin mittaiseksi.
Kuulostaa kyllä oudon hitaalta, vaikka kyseessä olisi SMR-levy ja USB 2.0-nopeudet. Pystytkö kokeilemaan levyä jossain toisessa tietokoneessa?
-
Kopionti meni siis suunnilleen niin, että esim. 4G erästä 1G vei muutaman minuutin (en seurannut tarkkaan) ja sitten kokonaisuus venähti yli tunnin mittaiseksi.
Kuulostaa kyllä oudon hitaalta, vaikka kyseessä olisi SMR-levy ja USB 2.0-nopeudet. Pystytkö kokeilemaan levyä jossain toisessa tietokoneessa?
Joo, mulla on kaksi läppäriä. Tuo ulkoinen levy on melko uusi ja tuntuu toimivan ihan normaalisti tässä Fujitsun koneessa, mutta sitten tuo hitaus tuli esille tuossa Lenovon koneessa ja siinäkin vasta isolla datamäärällä. Molemmissa samanlainen setup, eli Xubuntu 22.04 ja osa tiedostoista kryptattuna. Tässä tosin HDD ja Lenovossa SDD.
Oma mutuni oli, että se dekryptaus kestää, mutta on toki vain mutu vailla mitään varsinaista näyttöä asiasta. Sama LUKS toimii ok toisessa koneessa.
-
Kopionti meni siis suunnilleen niin, että esim. 4G erästä 1G vei muutaman minuutin (en seurannut tarkkaan) ja sitten kokonaisuus venähti yli tunnin mittaiseksi.
Kuulostaa kyllä oudon hitaalta, vaikka kyseessä olisi SMR-levy ja USB 2.0-nopeudet. Pystytkö kokeilemaan levyä jossain toisessa tietokoneessa?
Kyllä ne noin hitaaksi menee omien kokemusten perusteella, kun välimuisti poltettu loppuun ja aletaan kopioimaan todella pieniä tiedostoja. Kevyessä käytössä joku ehkä 60mt/s ja sitten kuvien yms. kopioinnissa kyykkää helposti 20mt/s paikkeille.
Tuolla on aika hyvä testi ja tuolla 12min kohdilla on aika shokeeraavat käppyrät ja nuo vielä pöytäkonekoossa. Läppäriasemat vielä huonompia.
https://www.youtube.com/watch?v=hAijmZsTd2A
Nämä on vähän sellaisia parikymmentä vuotta takkiin teknisesti hinnan takia
-
Kopionti meni siis suunnilleen niin, että esim. 4G erästä 1G vei muutaman minuutin (en seurannut tarkkaan) ja sitten kokonaisuus venähti yli tunnin mittaiseksi.
Kuulostaa kyllä oudon hitaalta, vaikka kyseessä olisi SMR-levy ja USB 2.0-nopeudet. Pystytkö kokeilemaan levyä jossain toisessa tietokoneessa?
Kyllä ne noin hitaaksi menee omien kokemusten perusteella, kun välimuisti poltettu loppuun ja aletaan kopioimaan todella pieniä tiedostoja. Kevyessä käytössä joku ehkä 60mt/s ja sitten kuvien yms. kopioinnissa kyykkää helposti 20mt/s paikkeille.
Joo mutta Snufkinin kertoman mukaan siirtonopeus on ollut luokkaa 1 Mt/s, ja kyseessä kuitenkin melko isot megatavukoon tiedostot. En oikein usko, että johtuu pelkästään levystä, ellei siinä ole jotain vikaa.
-
Oma mutuni oli, että se dekryptaus kestää, mutta on toki vain mutu vailla mitään varsinaista näyttöä asiasta. Sama LUKS toimii ok toisessa koneessa.
Dekryptaus ei voi olla noin hidasta. Se hidastaisi kaikkea normaalia käyttöä niin, että vaikkapa sovellusten käynnistäminen kestäisi minuutteja.
-
Oma mutuni oli, että se dekryptaus kestää, mutta on toki vain mutu vailla mitään varsinaista näyttöä asiasta. Sama LUKS toimii ok toisessa koneessa.
Dekryptaus ei voi olla noin hidasta. Se hidastaisi kaikkea normaalia käyttöä niin, että vaikkapa sovellusten käynnistäminen kestäisi minuutteja.
Voisiko se vaikuttaa, että kyseinen data on eräänlainen tietoarkisto, jota ei käytetä kovin paljoa tai kovin usein? Hakuja sinne ehkä muutaman kuukauden välein tai max muutama viikossa.
-
Joo mutta Snufkinin kertoman mukaan siirtonopeus on ollut luokkaa 1 Mt/s, ja kyseessä kuitenkin melko isot megatavukoon tiedostot. En oikein usko, että johtuu pelkästään levystä, ellei siinä ole jotain vikaa.
No juu. Tuo itse asiassa kyllä kuulostaa liian hitaalta. Omassa isossa terojen kopioinnissa keskiarvona noin 70mt/s, vaikka se on varmaankin jonkin verran kyllä yläkanttiin, koska kirjoitus keskeytyi pari kertaa ja levy on silloinkin "elvyttänyt" itseään.
-
Oma mutuni oli, että se dekryptaus kestää, mutta on toki vain mutu vailla mitään varsinaista näyttöä asiasta. Sama LUKS toimii ok toisessa koneessa.
Dekryptaus ei voi olla noin hidasta. Se hidastaisi kaikkea normaalia käyttöä niin, että vaikkapa sovellusten käynnistäminen kestäisi minuutteja.
Voisiko se vaikuttaa, että kyseinen data on eräänlainen tietoarkisto, jota ei käytetä kovin paljoa tai kovin usein? Hakuja sinne ehkä muutaman kuukauden välein tai max muutama viikossa.
En minä ainakaan Veracryptillä ja edes ulkoisella asemalla huomaa käytännössä mitään eroa normaaliin paikalliseen tiedostojen käyttöön X250:llä, joka on varmaan suorituskyvyltään hyvin lähellä sinun tapausta. En ainakaan tiedä, että tuossa välissä olisi CPU:n tullut mitään kryptauksiin merkittävästi vaikuttavaa tukea.
En kyllä varsinaisesti ole mitään benchmarkkia koskaan kokeillutkaan sisäisille asemille. Eli en usko lainkaan tuohon.
-
Voi myös johtua ulkoisen tallentimen ylikuumenemisesta, mikä hidastaa vauhtia. Jos on hyvin koteloitu, eikä pääse jäähtymään, niin voi hyvinkin johtua tuosta. Alumiinikuorinen USB tikkukin saattaa joskus kuumentua niin, että sormia polttaa.
-
Voi myös johtua ulkoisen tallentimen ylikuumenemisesta, mikä hidastaa vauhtia. Jos on hyvin koteloitu, eikä pääse jäähtymään, niin voi hyvinkin johtua tuosta. Alumiinikuorinen USB tikkukin saattaa joskus kuumentua niin, että sormia polttaa.
Tällainen edullinen peruskovo
(https://cf-images.dustin.eu/cdn-cgi/image/fit=contain,format=auto,quality=75,width=828,fit=contain/image/d200001001532966/seagate-basic-portable-5tb-external-hdd-hopea.jpg)
-
Aloin tuossa miettimään sellaista, että voisiko kyseessä olla ihan jonkinlainen bugi, että garbage collection on jotenkin liiallista. Toinen artikkeli oli jostain SMR ongelmista, jossa käyttäjä oli joutunut poistamaan välimuistin kokonaan asemien käytöstä ja tuolloin kirjoitusnopeus oli tipajtanut alle 8mb/s.
Tuossa nimittäin oirekuva tukisi aika hyvin jotain tuollaista jos asema tosiaan toimii parhaiten hetken aikaa ja jos kirjoitusmäärä rajataan johonkin. Voisi olla, että levy vain kerkeää palautua tuossa hetkellisesti.
Onko asema kuinka karkeasti kuinka täynnä ja onko sen käyttö ollut aina sellaista "paikoilleen, kopiointi ja irroitus" tyyppistä, vai onko asema ollut jossain vaiheessa pitempiä aikoja koneessa kiinni?
Tuossa aiemmin linkatussa videossa oli siinäkin mainittu, että Toshiban asemilla oli joutunut odottamaan yli 8h gc suoriutumista, että oli saanut luotettavia/vertailtavia testituloksia. Toki edelleen tuossakin testivideossa oli saatu asema kyykäämään noin 2,5Mt/s nopeuteen kun oli kirjoitettu putkeen 20% levytilavuudesta ja asema oli alkanut lukeen/kirjoittaan välimuistiin cg:n takia. Kuten videollakin mainitaan, niin yli 20% tilavuuden kirjoitus on harvinainen tapahtuma. Mutta näinhän se oli omassa pitkässäkin kopioinnissa. Se oli katkennut pariin kertaan verkkovirheen takia, varmaankin useammaksi tunniksi parhaillaan ja levy vaikutti olevan aktiivinen silti koko ajan, vaikka kopiointi oli keskeytynnyt.
Tuo asema on varmaankin hyvin lähellä samaa kuin omani, joka on 4teran versio. Samannäköinen Seagate.
-
Be aware though, if you want to encrypt them, that it takes a very long time on smr drives.
I once encrypted an 8 TB seagate smr drive with luks.
It took 14 days nonstop.
A 8 TB cmr drive takes ~ 26 hours.
14 päivää on aika pitkä aika 8 teran aseman kryptaukseen ja ei siinäkään enää nopeus päätä huimaa. Toki olisi kait tuokin vielä luokkaa 7mt/s.
-
Onko asema kuinka karkeasti kuinka täynnä ja onko sen käyttö ollut aina sellaista "paikoilleen, kopiointi ja irroitus" tyyppistä, vai onko asema ollut jossain vaiheessa pitempiä aikoja koneessa kiinni?
On melko uusi levy ja oikeastaan aina irti. Teen sille vain satunnaisesti varakopioita läppäri-katastrofin varalle. Tällöin kiinni ja tiedostojen kopiointi ja sitten irti.
-
Onko asema kuinka karkeasti kuinka täynnä ja onko sen käyttö ollut aina sellaista "paikoilleen, kopiointi ja irroitus" tyyppistä, vai onko asema ollut jossain vaiheessa pitempiä aikoja koneessa kiinni?
On melko uusi levy ja oikeastaan aina irti. Teen sille vain satunnaisesti varakopioita läppäri-katastrofin varalle. Tällöin kiinni ja tiedostojen kopiointi ja sitten irti.
Jotenkin sellainen kutina, että kannattaa ehkä jossain vaiheessa antaa olla aseman liitettynä vain "joutokäynnillä" kun tekee jotain. Se voi olla, että se vain kaipaa muutaman tunning GC-sessiota. Onko asemasta tuo yli 20% tilavuudesta nykyään käytettynä? Jos on, niin varsinkin siinä tapauksessa.
-
Onko asema kuinka karkeasti kuinka täynnä ja onko sen käyttö ollut aina sellaista "paikoilleen, kopiointi ja irroitus" tyyppistä, vai onko asema ollut jossain vaiheessa pitempiä aikoja koneessa kiinni?
On melko uusi levy ja oikeastaan aina irti. Teen sille vain satunnaisesti varakopioita läppäri-katastrofin varalle. Tällöin kiinni ja tiedostojen kopiointi ja sitten irti.
Jotenkin sellainen kutina, että kannattaa ehkä jossain vaiheessa antaa olla aseman liitettynä vain "joutokäynnillä" kun tekee jotain. Se voi olla, että se vain kaipaa muutaman tunning GC-sessiota. Onko asemasta tuo yli 20% tilavuudesta nykyään käytettynä? Jos on, niin varsinkin siinä tapauksessa.
Saattaa olla tuota luokkaa, että 20% käytössä. En nyt muista ulkoa, enkä ole nyt ko. kovon ääressä. Pitääpä kokeilla pitää sitä enemmän koneessa kiinni.
Mulla on tällainen hieman diy-varakopionti, että läppärien kovot -> ulkoinen kovo A -> ulkoinen kovo B, joka sitten pääsin eri paikassa. Eli jos talo palaa, niin aina jää sitten jotain talteen. :)
Hankalaa, kun pitää varautua teknisiin ongelmiin, varkauteen ja tulipaloon. Pilviinkään en oikein luota.
-
Mulla on tällainen hieman diy-varakopionti, että läppärien kovot -> ulkoinen kovo A -> ulkoinen kovo B, joka sitten pääsin eri paikassa. Eli jos talo palaa, niin aina jää sitten jotain talteen. :)
Hankalaa, kun pitää varautua teknisiin ongelmiin, varkauteen ja tulipaloon. Pilviinkään en oikein luota.
Jeps. Itsellä on 24/7 päällä oleva pieni 1L Proxmox serveri, jossa on sitten myös tiedostopalvelin. Tuon tiedostot on nyt sitten tarkoitus puolen vuoden välein synkronoida vastaavalle kryptatulle Seagate USB asemalle, joka on töissä pukukaapissa jemiksessä.
Proxmox palvelin on kyllä varmuuskopioitu PSB-palvelimelle, mutta se ei taas paljoa hyödytä kun kyseinen kone on käytännössä samassa tilassa. Pitäisi kyllä tehdä palvelimen varmuuskopioista myös joku vastaava USB-varmuuskopio. On sen konfaamiseen kuitenkin sen verran aikaa mennyt. No onpa ainakin ne tärkeimmät kuitenkin nyt muualla jemiksessä. Serverin nyt saa aina tehtyä uudelleen. Toki nyt kun tuli puheeksi, niin pitääkin tässä välissä ottaa heti paikalliset Trilium muistiinpanot talteen. Niitä en kyllä halua hukata.
-
Jeps. Itsellä on 24/7 päällä oleva pieni 1L Proxmox serveri, jossa on sitten myös tiedostopalvelin. Tuon tiedostot on nyt sitten tarkoitus puolen vuoden välein synkronoida vastaavalle kryptatulle Seagate USB asemalle, joka on töissä pukukaapissa jemiksessä.
Proxmox palvelin on kyllä varmuuskopioitu PSB-palvelimelle, mutta se ei taas paljoa hyödytä kun kyseinen kone on käytännössä samassa tilassa. Pitäisi kyllä tehdä palvelimen varmuuskopioista myös joku vastaava USB-varmuuskopio. On sen konfaamiseen kuitenkin sen verran aikaa mennyt. No onpa ainakin ne tärkeimmät kuitenkin nyt muualla jemiksessä. Serverin nyt saa aina tehtyä uudelleen. Toki nyt kun tuli puheeksi, niin pitääkin tässä välissä ottaa heti paikalliset Trilium muistiinpanot talteen. Niitä en kyllä halua hukata.
Itsellä myös Proxmox tutkinta ja kokeilut alkusuoralla. Mikä on tuo PSB-palvelin jonka mainitsit? Miten olet toteuttanut tiedostonjaon proxmox kanssa? Sellainen olisi myös itselle tarkoitus saada mutta en vielä päässyt selvyytteen mikä on paras tapa: truenas tms vai suoraan proxmox hostissa vai jotain muuta?
-
Jeps. Itsellä on 24/7 päällä oleva pieni 1L Proxmox serveri, jossa on sitten myös tiedostopalvelin. Tuon tiedostot on nyt sitten tarkoitus puolen vuoden välein synkronoida vastaavalle kryptatulle Seagate USB asemalle, joka on töissä pukukaapissa jemiksessä.
Proxmox palvelin on kyllä varmuuskopioitu PSB-palvelimelle, mutta se ei taas paljoa hyödytä kun kyseinen kone on käytännössä samassa tilassa. Pitäisi kyllä tehdä palvelimen varmuuskopioista myös joku vastaava USB-varmuuskopio. On sen konfaamiseen kuitenkin sen verran aikaa mennyt. No onpa ainakin ne tärkeimmät kuitenkin nyt muualla jemiksessä. Serverin nyt saa aina tehtyä uudelleen. Toki nyt kun tuli puheeksi, niin pitääkin tässä välissä ottaa heti paikalliset Trilium muistiinpanot talteen. Niitä en kyllä halua hukata.
Itsellä myös Proxmox tutkinta ja kokeilut alkusuoralla. Mikä on tuo PSB-palvelin jonka mainitsit? Miten olet toteuttanut tiedostonjaon proxmox kanssa? Sellainen olisi myös itselle tarkoitus saada mutta en vielä päässyt selvyytteen mikä on paras tapa: truenas tms vai suoraan proxmox hostissa vai jotain muuta?
Se on ihan Proxmoxin virallinen varmuuskopiointipalvelin
https://www.proxmox.com/en/products/proxmox-backup-server/overview
Se on hyvinkin helppo laittaa toimintaan. Itsellä on ikivanha todella tehoton Intel NUC, johon laitoin 8gt muistia ja siihen on itse asiassa asennettu Proxmox palvelin ja yhdeksi VM koneeksi sitten tuo PBS. Natiivi asennus toki olisi varmaan paras, mutta oli ajatuksena, että jos tuohon muistimäärään saa vielä mahdutettua vielä jonkin, vaikka UrBackup palvelimen erilliseksi palveluksi.
Jonkin aikaa ajattelin tuon olevan ihan ylilyöty ratkaisu pieneen kotiserveriin, mutta sitten tajusin, että se on oikeastaan ainoa oikea ratkaisu, koska se tukee niin hyvin deduplikaatiota, eli itselläkin on tällä hetkellä deduplikation factor arvossa 10,57. Eli 6kpl virtuaalikoneita, joista varmuuskopiona 66 snapshottia ja 4kpl kontainereita joista tällä hetkellä 49 snapshottia, niin näiden varmuuskopiot veisi tavalliselle verkkoasemalle kopioituna tuon 10,57 kertaa isomman tilan. Itsellä on 730Gt varattu PSB:lle varmuuskopiotilaa, josta käytössä 598G ja silti jos koneiden koot ei muutu, niin PBS näyttää nyt automaattisesti, että varmuuskopiointi tila tulee täyteen 201 päivän päästä nykyisellä käytöllä. Muutenkin tuo on oikein kiva, kun se toimii käytännössä saumattomasti Proxmoxin kanssa. Periaatteessa kun on samassa verkossa, niin PBS:tä otetaan avain ja syötetään se Proxmoxiin, niin homma toimii melkeinpä automaattisesti sen jälkeen. Itsellä on varmuuskopiot kerran viikossa sunnuntai öisin ja tuosta nyt kun katsoo backup listaa kyseisen kontainerin kohdalta, niin voisin palauttaa sen 2024 elokuuhun saakka kuukauden välein. Eli kahden viikon varmuuskopiot on itsellä säilytyksessä ja sitten karsitaan varmuuskopiot niin, että jätetään kuukausittainen varmuuskopio. Sitten tietysti se tärkein, että nuo varmuuskopioiden palautukset on ainakin toistaiseksi toiminut itsellä ihan älyttömän hyvin. Juuri pari viikkoa sitten huomasin, että OpenMediaVault, joka pyörii Proxmoxin VM:nä, oli pahasti jäänyt itsellä päivittämättä. Katsoin, että datat sen osalta on hyvin varmuuskopioituna ja yritin päivittää tuon VM:n ja jotain meni pahasti pieleen. Napsuttelin muutaman kuukauden takaisen varmuuskopion, joka parin napin painalluksen jälkeen ja ehkä minuutin latauksen jälkeen palautettu, kokeilin päivittää hiukan erilailla ja taas on OpenMediaVault kunnossa. Samoin kun satunnaisesti kikkaillut HomeAssistantin kanssa, jonka saan ainakin itse rikottua, niin ihan mahtava vain painaa "backup now" ja jos jotain ryssii, niin palautus onnistuu ihan älyttömän nopeasti tuohon tilaan. Muutenkin tuossa voi tehdä todella helposti jonkin palautuspisteen ja vaikka kiinnittää sen niin, että sitä ei koskaan poisteta, vaikkapa esim. joku ajantasalle päivitetty Windows VM tms. voisi olla hyvä kohde tuollaiseen. Yhtenä mukanavana mielenrauhaa lisäävänä toimintona tuo vielä tekee varmuuskopioiden varmistustestit halutulla ajanjaksolla ja ilmoittaa jos varmuuskopiot alkaa korruptoitumaan tms. Itsellä tuo vanha tehoton NUC tekee siis kerran kuukaudessa varmuuskopioiden tarkistukset. Kestää pari tuntia tuollaisella todella tehottomalla koneella (2013 vuoden tuplaydin Celeron, joka käyttökelvoton nykyään melkein kaikkeen)
Eli ei mitään negatiivista sanottavaa. No se nyt tietysti, että ollut juttua, että siihen olisi ehkä jossain vaiheessa tulossa tukea muidenkin järjestelmien varmuuskopiointiin, niin sehän olisi vielä bonusta. Mutta jos Proxmox ja siihen on jo käyttänyt aikaa konffailuun ja varmuuskopiointi alkaa olla ajankohtaista, niin ihan ehdottomasti PBS käyttöön.
Kannattaa tsekata ElectronicsWizardyn Proxmox jutut. Ehkä YouTuben paras lähde moniin juttuihin. Tuossa on linkki hänen PBS videoon.
https://www.youtube.com/watch?v=Px5eHcUKbbQ
Tuon PBS avulla itse asiassa siirsin koko Proxmox serverin ihan eri raudalle parissa tunnissa. Varmuuskopiot vain kaikista. Uuteen koneeseen nopea Proxmox asennus ja datan palautus PBS:tä. Eli siinäkin mielessä varsin näppärä siirtää noita VM/CT asennuksia eri koneisiin.
-
Onko asema kuinka karkeasti kuinka täynnä ja onko sen käyttö ollut aina sellaista "paikoilleen, kopiointi ja irroitus" tyyppistä, vai onko asema ollut jossain vaiheessa pitempiä aikoja koneessa kiinni?
On melko uusi levy ja oikeastaan aina irti. Teen sille vain satunnaisesti varakopioita läppäri-katastrofin varalle. Tällöin kiinni ja tiedostojen kopiointi ja sitten irti.
Mikä tiedostojärjestelmä? Fat ainakin on tuhottoman hidas jos hakemistossa on paljon tiedostoja. Itsellä on valokuville 4T Seagate varmuuskäyttöön ja toimii kivasti kun kopioitavat koot suhteellisen pieniä - noin 30G kerrallaan. Tiedostojärjestelmä jostain syystä xfs
-
Mikä tiedostojärjestelmä? Fat ainakin on tuhottoman hidas jos hakemistossa on paljon tiedostoja. Itsellä on valokuville 4T Seagate varmuuskäyttöön ja toimii kivasti kun kopioitavat koot suhteellisen pieniä - noin 30G kerrallaan. Tiedostojärjestelmä jostain syystä xfs
En nyt muista, mutta ei pitäisi olla siitä kiinni, koska kopiointi aluksi nopeaa.
-
En nyt muista, mutta ei pitäisi olla siitä kiinni, koska kopiointi aluksi nopeaa.
Alun nopea kopioiminen voi johtua Linuxin levyvälimuistista, eli tiedostot kopioidaan RAM-muistiin odottamaan varsinaista kirjoitusta levylle. Kirjoitusprosessi etenee taustalla omaan tahtiinsa, mutta aluksi voi tosiaan vaikuttaa siltä, että kopiointi etenee vauhdikkaasti. Levyvälimuistin koko riippuu vapaan muistin määrästä. Yleensä sitä on ainakin gigatavun verran, ellei muisti ole vähissä.
-
Onko asema kuinka karkeasti kuinka täynnä ja onko sen käyttö ollut aina sellaista "paikoilleen, kopiointi ja irroitus" tyyppistä, vai onko asema ollut jossain vaiheessa pitempiä aikoja koneessa kiinni?
On melko uusi levy ja oikeastaan aina irti. Teen sille vain satunnaisesti varakopioita läppäri-katastrofin varalle. Tällöin kiinni ja tiedostojen kopiointi ja sitten irti.
Mikä tiedostojärjestelmä? Fat ainakin on tuhottoman hidas jos hakemistossa on paljon tiedostoja. Itsellä on valokuville 4T Seagate varmuuskäyttöön ja toimii kivasti kun kopioitavat koot suhteellisen pieniä - noin 30G kerrallaan. Tiedostojärjestelmä jostain syystä xfs
Ei sillä ollut oikeastaan mitään merkitystä. Taitaa olla nyt exFAT että toimii varmasti kaikissa koneissa. Niin kuin jo aiemmin mainitsin, niin se joku 10-30Gt menee kivasti ja sitten jäätyy.
-
Mikä tiedostojärjestelmä? Fat ainakin on tuhottoman hidas jos hakemistossa on paljon tiedostoja. Itsellä on valokuville 4T Seagate varmuuskäyttöön ja toimii kivasti kun kopioitavat koot suhteellisen pieniä - noin 30G kerrallaan. Tiedostojärjestelmä jostain syystä xfs
Ei sillä ollut oikeastaan mitään merkitystä. Taitaa olla nyt exFAT että toimii varmasti kaikissa koneissa. Niin kuin jo aiemmin mainitsin, niin se joku 10-30Gt menee kivasti ja sitten jäätyy.
[/quote]
FAT-levy on hidas jos paljon pieniä tiedostoja. Se käyttää listaa joka luetaan aina alusta loppuun. Toki koneen välimuisti auttaa, mutta kun se täyttyy nopeus romahtaa. Binääripuu on listaan verrattuna paljon nopeampi. exFAT tukea ei taida olla vanhemmissa koneissa. Toki sen voi yleensä asentaa. Voit testata huviksesi tikulla.
-
Mikä tiedostojärjestelmä? Fat ainakin on tuhottoman hidas jos hakemistossa on paljon tiedostoja. Itsellä on valokuville 4T Seagate varmuuskäyttöön ja toimii kivasti kun kopioitavat koot suhteellisen pieniä - noin 30G kerrallaan. Tiedostojärjestelmä jostain syystä xfs
Ei sillä ollut oikeastaan mitään merkitystä. Taitaa olla nyt exFAT että toimii varmasti kaikissa koneissa. Niin kuin jo aiemmin mainitsin, niin se joku 10-30Gt menee kivasti ja sitten jäätyy.
FAT-levy on hidas jos paljon pieniä tiedostoja. Se käyttää listaa joka luetaan aina alusta loppuun. Toki koneen välimuisti auttaa, mutta kun se täyttyy nopeus romahtaa. Binääripuu on listaan verrattuna paljon nopeampi. exFAT tukea ei taida olla vanhemmissa koneissa. Toki sen voi yleensä asentaa. Voit testata huviksesi tikulla.
[/quote]En oikein usko tuohon, kun omassa kopioinnissa oli myös kymmenien gigatavujen yksittäisiä järjestelmäpalautustiedostoja. Toki myös iso nippu pienempiä. Mutta kuitenkin ihan yhtä hidasta näytti olevan oli sitten kyseessä isot tai pienet tiedostot. Kävi kyllä mielessä, että yksi vaihtoehto olisi ehkä ollut vain tehdä salasanapakattu tiedosto ensin jollekin muulle asemalle ja sitten kokeilla kopioida se kerralla tuolle asemalle. Mutta nyt kun kopiointi on viimein tehty, niin freefilesyncillä ei pitäisi hirveän kauaa enää mennä päivitellä tyyliin joitain gigatavuja sitten puolivuosittain asemalle. Johonkin pakattuun tiedostoon tuo olisi varsin ärsyttävä muutos jatkossa.
-
Uusi kokeilu ja sama vanha ongelma. Ensimmäinen 2G meni nyt suhteellisen nopeasti koneen omalta kovolta ulkoiselle usb-portin kautta, mutta sitten homma hidastui merkittävästi.
Nyt katkaisin siirron ja aloitin uudelleen niin, että se skippaa jo olemassa olevat. Edelleen tolkuttoman hidas.
Lähde on 500G HDD ja kohde 1T Seagete HDD
-
Seuraava yritys 4,G kuormalla hyytyi (hidastui merkittävästi) 500M kohdalla. :(
Tuollainen ohjelma kuin thumblerd, joka jonkinlainen Thunarin apulainen tuntuu haukkaavan kovasti prosessoriaikaa. Pitääpä kokeilla jotain muuta tiedosto-ohjelmaa. Tuon thumblerin ongelmista on juttua netissä kyllä. Edit: haukkaa enimmillään 38% prosessoriajasta.
-
Eipä se olekaan vika Thunarissa. Kokeilen toisella ohjelmalla (Krusader) ja sama hitaus alkoi noin 2GB kohdalla, eikä tuo thumlerd käynnistynyt tällä ohjelmalla.
Vian etsintä jatkuu...
-
Kuten aiemmin totesin, levyvälimuisti vaikuttaa nopeuteen siirron alussa. Käytännössä lähdelevyn lukunopeus määrää silloin siirtonopeuden, mutta data siirtyy vain keskusmuistissa sijaitsevaan kernelin levyvälimuistiin. Varsinainen kirjoitus on tässä sinun tapauksessasi todennäköisesti koko ajan yhtä hidasta.
-
Kuten aiemmin totesin, levyvälimuisti vaikuttaa nopeuteen siirron alussa. Käytännössä lähdelevyn lukunopeus määrää silloin siirtonopeuden, mutta data siirtyy vain keskusmuistissa sijaitsevaan kernelin levyvälimuistiin. Varsinainen kirjoitus on tässä sinun tapauksessasi todennäköisesti koko ajan yhtä hidasta.
Voiko tuohon välimuistin kokoon vaikuttaa? Onko se sama kuin tuo SWAP? Minulla on se 2G, mutta oli tuolloin hidastuessa vain noin 50% käytössä. Keskusmuistia on 12G.
Onko olemassa jotain tapaa mitata noita luku ja kirjoitusnopeuksia per levy?
-
Voiko tuohon välimuistin kokoon vaikuttaa? Onko se sama kuin tuo SWAP?
Ei ole sama asia. Tuo välimuisti toteutuu ihan kernelin ohjaamana kuten nm mainitsi. Eli luetaan tai kirjoitetaan keskusmuistiin ensin tai oikeastaan voi sanoa, että sinne aletaan puskuroida kun levytoimminnot ei pysy enää mukana. Swap on taas keskusmuistin jatke. Eli jos keskusmuisti loppuisi, niin muistin puutos korvataan levylle kirjoittamalla, joka on aina ei toivottu tapahtuma, mutta swappia on hyvä yleensä varmuuden vuoksi olla pieni määrä jos muisti täyttyy, niin järjestelmä ei välttämättä sitten kaadu kokonaan.
Onko olemassa jotain tapaa mitata noita luku ja kirjoitusnopeuksia per levy?
On paljonkin. Jossain määrin näet ihan sieltä käyttiksestä, riippuen vähän mikä UI on käytössä, mutta esim. Gnomessa järjestelmämonitorilla jos nyt nimen muistan oikein. Toki vain hetkellisesti. Sieltä muuten muistista näkee myös tuon välimuistin määrään jos se sattuu kiinnostamaan. Sitä kun seuraa kun on toimintoja päällä, niin se elää aika paljon.
Gnomessa taitaa sillä oletuslevytyökalulla pystyä muuten testaamaan asemia. Sitten on vaikka KDiskMarkilla voi oikein testata tarkemmin asemia Flathubissa jne.
https://flathub.org/en/apps/io.github.jonmagon.kdiskmark
Vaihtoehtoja kyllä löytyy.
-
Levyn sisäisessä kopioinnissa (kansiosta toiseen) tätä ilmiötä ei tapahdu. Juuri siisrin 3,9G melko nopeasti
-
Levyn sisäisessä kopioinnissa (kansiosta toiseen) tätä ilmiötä ei tapahdu. Juuri siisrin 3,9G melko nopeasti
Joo, vika tuntuu liittyvän jotenkin ulkoisen levyn ja koneen USB-kontrollerin toimintaan laitetasolla. Siirtonopeus jää jostain syystä USB 1.1-standardin mukaiseksi eli n. 1 Mt/s.
Mitä muuten lsusb:n tarkempi listaus kertoo ulkoisen levyn kytkennästä:
lsusb --tree
-
Mitä muuten lsusb:n tarkempi listaus kertoo ulkoisen levyn kytkennästä:
lsusb --tree
$ lsusb --tree
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
|__ Port 5: Dev 2, If 0, Class=Hub, Driver=hub/4p, 12M
|__ Port 2: Dev 4, If 0, Class=Chip/SmartCard, Driver=, 12M
|__ Port 8: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 8: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
|__ Port 11: Dev 6, If 13, Class=CDC Data, Driver=cdc_mbim, 480M
|__ Port 11: Dev 6, If 12, Class=Communications, Driver=cdc_mbim, 480M
|__ Port 12: Dev 7, If 1, Class=Video, Driver=uvcvideo, 480M
|__ Port 12: Dev 7, If 0, Class=Video, Driver=uvcvideo, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
|__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 4, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
-
Mitä muuten lsusb:n tarkempi listaus kertoo ulkoisen levyn kytkennästä:
lsusb --tree
$ lsusb --tree
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
|__ Port 5: Dev 2, If 0, Class=Hub, Driver=hub/4p, 12M
|__ Port 2: Dev 4, If 0, Class=Chip/SmartCard, Driver=, 12M
|__ Port 8: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 8: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
|__ Port 11: Dev 6, If 13, Class=CDC Data, Driver=cdc_mbim, 480M
|__ Port 11: Dev 6, If 12, Class=Communications, Driver=cdc_mbim, 480M
|__ Port 12: Dev 7, If 1, Class=Video, Driver=uvcvideo, 480M
|__ Port 12: Dev 7, If 0, Class=Video, Driver=uvcvideo, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
|__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 4, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
Sulla on liian vanhanaikainen USB-hubi siellä välissä.
Eipäs mitään, katsoin väärin.
-
Ei ole mitään välissä. Kone on kyllä vanha
-
Ei ole mitään välissä. Kone on kyllä vanha
Juu ei mitään, katsoin ihan väärin.
-
Spekseistä
Interfaces
USB 3.0 total 3 (1 with Anytime USB Charge functionality)
USB 2.0 total 1
Yksi museohubi on systeemissä, jakaa hiiren ja näppäimistön KVM-kytkimen kautta, mutta ei pitäisi kyllä vaikuttaa tuon kovon toimintaan.
-
$ lsusb --tree
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas,
Levy näyttää kytkeytyvän nopeana USB 3 -laitteena, eli ei näytä ainakaan tunnistusongelmalta. Yksi mahdollinen syy voisi olla siirron aikana syntyvät virheet, joiden korjaaminen vaatii siirtopakettien uudelleenlähetyksen. Sellainen voisi hyvinkin hidastaa siirtoa megatavuluokkaan.
Kokeilitko levyä jo kaikissa koneen USB-porteissa? Pystytkö kokeilemaan toisella USB-johdolla?
-
Spekseistä
Interfaces
USB 3.0 total 3 (1 with Anytime USB Charge functionality)
USB 2.0 total 1
Yksi museohubi on systeemissä, jakaa hiiren ja näppäimistön KVM-kytkimen kautta, mutta ei pitäisi kyllä vaikuttaa tuon kovon toimintaan.
Kokeile ilman sitä. Kyllä ne voi joskus sekoittaa järjestelmää ja pakottaa jotain taaksepäinyhteensopivuustilaan, eli hitaampaan tilaan. Mitä vanhempi laite, sitä todennäköisempää.
Onhan sinulla se asema vasemmalla puolella näyttöliittimien välissä kiinni?
-
$ lsusb --tree
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas,
Levy näyttää kytkeytyvän nopeana USB 3 -laitteena, eli ei näytä ainakaan tunnistusongelmalta. Yksi mahdollinen syy voisi olla siirron aikana syntyvät virheet, joiden korjaaminen vaatii siirtopakettien uudelleenlähetyksen. Sellainen voisi hyvinkin hidastaa siirtoa megatavuluokkaan.
Kokeilitko levyä jo kaikissa koneen USB-porteissa? Pystytkö kokeilemaan toisella USB-johdolla?
Mä otan nää työn alle, en pysty nyt testaamaan kun muu työ kesken. Mulla on kaksi samanlaista Seagatea ja pitää kokeilla myös tuo johto. Toisaalta nopea alku (1-2G) viittaa siihen, ettei vika ole laitepuolella.
-
Mä otan nää työn alle, en pysty nyt testaamaan kun muu työ kesken. Mulla on kaksi samanlaista Seagatea ja pitää kokeilla myös tuo johto. Toisaalta nopea alku (1-2G) viittaa siihen, ettei vika ole laitepuolella.
Tuohon saa luottaa vain jos se on "benchmark" luotettavaa tietoa. Muuten se levyvälimuisti voi hämätä todella rajusti. Näet sen jo siitä, että jos kopioit tuon 1-2gt dataa asemalle ja heti kun se kopiointimerkki lähtee näkyvistä, niin napsauta aseman irroitusta. Käytännössä varmasti menee aika pitkään, että järjestelmä antaa oikeasti ilmoituksen aseman turvallisesta irroittamisesta, eli asema vielä kopioi dataa vaikka näennäisesti tapahtuman pitäisi olla loppunut.
-
Levyn sisäisessä kopioinnissa (kansiosta toiseen) tätä ilmiötä ei tapahdu. Juuri siisrin 3,9G melko nopeasti
Siinä ei välttämättä tarvi kummemmin dataa liikutella, kun lähinnä muutellaan datan kirjauksia, ts. miten mihinkin fyysiseen kohtaan linkitetään.
-
Levyn sisäisessä kopioinnissa (kansiosta toiseen) tätä ilmiötä ei tapahdu. Juuri siisrin 3,9G melko nopeasti
Siinä ei välttämättä tarvi kummemmin dataa liikutella, kun lähinnä muutellaan datan kirjauksia, ts. miten mihinkin fyysiseen kohtaan linkitetään.
Kyllähän kopionnissa kaikki data liikkuu, kun siitä luodaan uusi kopio.
-
Kyllähän kopionnissa kaikki data liikkuu, kun siitä luodaan uusi kopio.
Ei ole enää nykyään itsestään selvyys. Deduplikaatio on nykyään yleistä aika monissa tapauksissa.
-
Komentorivillä cp -a lähde kohde ihan tehokas. Rync -av myös kiva. Muistaakseni teran kopioiminen kesti jotain 6h USB 2 portin kautta. Pitää vaan odotella. Tutustu rsync ohjelman vipuihin.
-
Jatketaanpa tarinaa, eli hitaus jatkuu.
- Tänään koitin varakopioida noin 2G dataa ja 1G menee ok, sitten hyytyy.
- Laitoin Cancel ja kopiointi keskeytyi
- Sitten koitin umountata levyn, mutta ei enää onnistu.
- Kytkin koneeseen yhden usb-tikun ja ne näkyvät nyt eri tavalla tuolla /media-kansiossa.
$ ls
KINGSTON 'Seagate Basic'
Tulee kuvien kaltaisia varotuksia, vaikka mitään dataa ei pitäsi olla kirjoituksessa ja levy ollut still-tilassa jo minuutteja.
Se noissa on mielenkiintoista, että levyn nimi ei ole sdb vaan sdb1
/dev/sdb1 976759804 296885044 679874760 31% /media/xxx/Seagate Basic
/dev/sdc1 987360 450320 537040 46% /media/xxx/KINGSTON
- Sitten sammutin ja käynnistin tiedostoselaimen (Thunar) uudelleen, ei vaikutusta.
- Sitten irroitin kovalevyn väkisin ja sen seurauksena kaikki aiemmin kopioidut tiedosto ovat kadonneet, mutta levy toimii muuten ok.
Mistä lähtisi etsimää vikaa?
Edit: Uusi havainto. Noin 10 min kuluttua levy unmouonttaantui normaalisi. ja nyt tiedostot ovat tallella. Eli tekeekö se sittenkin tuon kopionnin jotenkin loppuun vaikka sen näennäisesti keskeyttää? Samoin uusi kopionti lähtee nyt käyntiin vauhdilla.
-
Ihan perus settiä. Tiedostot on vielä välimuistissa. Juuri siksi se kopiointi vaikuttaa alkuun nopealta ja sitten jymähtää hitaaksi.
-
Ihan perus settiä. Tiedostot on vielä välimuistissa. Juuri siksi se kopiointi vaikuttaa alkuun nopealta ja sitten jymähtää hitaaksi.
Missä välimuistissa? Tietokoneen vai jossain kovalevyn porstuassa?
Ja miksi tuo cancel ei sitten keskeytä latausta, vaikka niin näyttää tekevän?
-
Lähes varmasti kummassakin jos iso tiedostomäärä kyseessä. Kyllähän se cancel sinullakin siinä toimi ihan niin kuin pitää. Se muisti/tapahtumat/tilanne vain pitää huuhtoa asemille, muuten se tieto häviää kun virrat häviää.
-
Löytyi uuttaa tietoa. Tein piruuttani kokeen, että latasin saman 2,3G datan kahdelle eri ulkoiselle levylle. Molemmat Seagate 1T, mutta hieman eri malleja. Toinen, joka vielä LUKS-kryptattu, selvityi tuosta sutjakasti. Tuo toinen sitten taas hyytyi, nyt 1,8G kohdalla.
Sitten vertailin levyjä Disks-ohjelmalla ja huomasin, että tuossa toisessa on NTFS-tiedostoformaatti! Voisiko tämä olla syy isojen datamäärien hitauteen? (Toisessa ext4)
-
Itsellä on kyllä NTFS:t nekin toiminut aika normaalisti. Toki voi kait siellä periaatteessa olla joku lohkoko tms. jotenkin huonosti soveltuva, ehkä? Se että asemat on saman merkkisiä ei kyllä kerro vielä mitään. Siellä silti voisi olla esim. toisessa CMR ja toisessa SMR asema sisällä ja niitä ei oikein tietäisi kun purkamalla asemat ja katsomalla kiintolevystä itsestään tarkan mallin ja tutkimalla.
Jos sulla on tilaa puljata väliaikaisesti nuo tiedostot johonkin, niin eihän tuo paha homma ole kokeilla alustaa uusiksi.
Mutta... esim. Seagaten perus halpis kiintolevy ST1000LM048 käyttää SMR tekniikkaa, eli on sitä huonompaa tekniikkaa. Siinäkin on välimuistia itsessään tuo 128Mt, eli voisi kuvitella, että joku tuollainen menee polvilleen jossain gigatavun kopioinnin kohdalla. Vastaava CMR asema ST1000LM049 varmaankin porskuttelee taas tuon 160Mt/s
Huvikseni kysyin Geminiltä "best/worst case scenarion" ja antoi vastauksenNopeuserot: CMR vs. SMR (1TB 2.5" HDD)
1 teratavun (TB) 2.5 tuuman SMR- ja CMR-kiintolevyjen nopeuksien välillä on merkittäviä eroja riippuen käyttötilanteesta.
Parhaassa tapauksessa molemmat asemat toimivat lähes samalla nopeudella. Kun kirjoitat suuria, peräkkäisiä tiedostoja tyhjälle levylle, nopeudet ovat tyypillisesti noin 80–160 megatavua sekunnissa (MB/s). SMR-asemat pystyvät tähän hyödyntämällä pientä, nopeaa välimuistialuettaan.
Sen sijaan pahimmassa tapauksessa ero on dramaattinen. Jos suoritat jatkuvia, satunnaisia kirjoituksia (esimerkiksi käytät levyä käyttöjärjestelmänä tai suuressa moniajossa) tai jos levy on lähes täynnä, SMR-aseman suorituskyky romahtaa. Nopeudet voivat pudota jopa 2.5–10 MB/s tasolle, koska asema joutuu käyttämään aikaa tietojen uudelleenjärjestelyyn. CMR-asema (Conventional Magnetic Recording) säilyttää tällaisessa tilanteessa tasaisen suorituskyvyn, pysyen jatkuvasti tuossa 80–160 MB/s nopeusikkunassa.
Lukunopeudet ovat molemmissa tekniikoissa vertailukelpoiset; ero ilmenee vain kirjoitustoiminnassa.
Yhteenvetona voidaan todeta, että SMR on edullisempi ja sopii parhaiten "kirjoita kerran, lue monta" -tyyppiseen arkistointiin ja kylmään varmuuskopiointiin. CMR on ylivoimainen valinta yleiskäyttöön ja suorituskykyä vaativiin tehtäviin, joissa tarvitaan tasaista ja ennustettavaa kirjoitusnopeutta.
Tosiaan tuossa on vielä hyvänä lisänä tuo, että CMR asema on hitaampi täyttyessään. Eli se tavallaan tekee sitä ikivanhaa defragmentointia kokoajan ja se toiminto hidastuu kun ei ole soluja mihin tuota toimintoa järkevästi tehdä.
Ja vielä lisähuomatuksena, että nuo ulkoiset asemathan on nykyään varsin edukkaita ja se tarkoittaa käytännössä automaattisesti sitä, että niihin kyllä tungetaan ne hinnat alkaen kiintolevyt sisälle.
Anna kun arvaan. Se vanhempi asema on merkittävästi nopeammalta tuntuva?
-
- Kytkin koneeseen yhden usb-tikun ja ne näkyvät nyt eri tavalla tuolla /media-kansiossa.
$ ls
KINGSTON 'Seagate Basic'
Tuolta pitääkin näyttää, jos siellä on kaksi mediaa liitettynä.
Se noissa on mielenkiintoista, että levyn nimi ei ole sdb vaan sdb1
Levyn laitetunnus on sdb, osion tunnus on sdb1. Näin kuuluu olla.
Ihan perus settiä. Tiedostot on vielä välimuistissa. Juuri siksi se kopiointi vaikuttaa alkuun nopealta ja sitten jymähtää hitaaksi.
Missä välimuistissa? Tietokoneen vai jossain kovalevyn porstuassa?
Koska umount ja fsync toimivat hitaasti, kopioitava data on kernelin välimuistissa eli tietokoneen ja käyttöjärjestelmän puolella, kuten on ollut jo pari kertaa aiemmin puhetta:
Alun nopea kopioiminen voi johtua Linuxin levyvälimuistista, eli tiedostot kopioidaan RAM-muistiin odottamaan varsinaista kirjoitusta levylle. Kirjoitusprosessi etenee taustalla omaan tahtiinsa, mutta aluksi voi tosiaan vaikuttaa siltä, että kopiointi etenee vauhdikkaasti. Levyvälimuistin koko riippuu vapaan muistin määrästä. Yleensä sitä on ainakin gigatavun verran, ellei muisti ole vähissä.
Kuten aiemmin totesin, levyvälimuisti vaikuttaa nopeuteen siirron alussa. Käytännössä lähdelevyn lukunopeus määrää silloin siirtonopeuden, mutta data siirtyy vain keskusmuistissa sijaitsevaan kernelin levyvälimuistiin. Varsinainen kirjoitus on tässä sinun tapauksessasi todennäköisesti koko ajan yhtä hidasta.
Ja miksi tuo cancel ei sitten keskeytä latausta, vaikka niin näyttää tekevän?
Tiedostoselaimen Cancel-toiminto ei taida pystyä perumaan kernelin välimuistiin ehtinyttä osaa siirrosta, vaan se jää valumaan levylle. Sitten kun kaikki on saatu kirjoitettua, kernelin välimuistissa on taas pari gigatavua tilaa odottelemassa uutta dataa.
Levyn omassa välimuistissa ei tällä 1 Mt/s siirtonopeudella ole paljon mitään. Nythän oli ymmärtääkseni niin, että sama levy toimi toisessa koneessa (Fujitsussa) hidastelematta, jolloin vika ei ole levyssä itsessään, vaan levyn ja tämän ongelmakoneen (Lenovon) välisessä kytkennässä. USB-yhteyden tiedot tutkittiin myös jo, ja se toimii näennäisesti USB 3 -standardilla, mutta siirtonopeus jää siitä huolimatta erittäin alhaiseksi. En keksi tähän muuta syytä kuin jokin laitteistotason epäyhteensopivuus levyn ja tietokoneen USB-ohjaimen välillä tai fyysisessä kytkennässä, jolloin virheenkorjaus hidastaa siirtoa.
Jos taas samaa hidastelua ilmenee muissakin koneissa, voisi epäillä syyksi SMR:ää tai levyn sisäistä vikaa. SMR ei kuitenkaan normaalisti toimi noin hitaasti, kun kyseessä on uudehko levy, eli osiolla on todennäköisesti vapaata tilaa, eikä se ole täysin fragmentoitunut. Nythän nämä hidastelevat siirrotkin ovat yhtenäistä kopiointia, eivätkä satunnaista kirjoittelua eri puolille levyä.
Sitten vertailin levyjä Disks-ohjelmalla ja huomasin, että tuossa toisessa on NTFS-tiedostoformaatti! Voisiko tämä olla syy isojen datamäärien hitauteen? (Toisessa ext4)
No ei ehkä ole täysin poissuljettu vaihtoehto, että ongelma johtuisi Linuxin NTFS-ajurista. Normaalia tällainen ei kuitenkaan ole, enkä ole törmännyt vastaavaan tapaukseen. Mikä käyttöjärjestelmä siinä Fujitsussa on, jolla levy toimii normaalisti?
-
Nythän oli ymmärtääkseni niin, että sama levy toimi toisessa koneessa (Fujitsussa) hidastelematta, jolloin vika ei ole levyssä itsessään, vaan levyn ja tämän ongelmakoneen (Lenovon) välisessä kytkennässä.
Näin oli aiemmin. Nyt tuo samainen levy alkoi hidastella Fujitsussa. Toisaalta en ole mitenkään systemaattisesti seurannut asiaa, mutta nyt olen melko varma asiasta.
Jos taas samaa hidastelua ilmenee muissakin koneissa, voisi epäillä syyksi SMR:ää tai levyn sisäistä vikaa. SMR ei kuitenkaan normaalisti toimi noin hitaasti, kun kyseessä on uudehko levy, eli osiolla on todennäköisesti vapaata tilaa, eikä se ole täysin fragmentoitunut. Nythän nämä hidastelevat siirrotkin ovat yhtenäistä kopiointia, eivätkä satunnaista kirjoittelua eri puolille levyä.
Kummassakin levyssä alle 50% dataa ja kumpikin "varakopiokäytössä" eli ei päivittäisessä.
Seagate Basic Portable Drive P/N 2URAP8-500 1TB (ongelmalevy)
Seagaet Expansion+ P/N 1V9AP9-500 1TB (ehkä ok toimiva)
Noista tuo Expansion+ on kympin tai pari kalliimpi malli. Kumpinkin sitä edullista päätä kuitenkin.
Sitten vertailin levyjä Disks-ohjelmalla ja huomasin, että tuossa toisessa on NTFS-tiedostoformaatti! Voisiko tämä olla syy isojen datamäärien hitauteen? (Toisessa ext4)
No ei ehkä ole täysin poissuljettu vaihtoehto, että ongelma johtuisi Linuxin NTFS-ajurista. Normaalia tällainen ei kuitenkaan ole, enkä ole törmännyt vastaavaan tapaukseen. Mikä käyttöjärjestelmä siinä Fujitsussa on, jolla levy toimii normaalisti?
[/quote]
Molemmissa koneissa on sama Xubuntu 22.04 LTS
-
Seagate Basic Portable Drive P/N 2URAP8-500 1TB (ongelmalevy)
Seagaet Expansion+ P/N 1V9AP9-500 1TB (ehkä ok toimiva)
Nettitietojen ja teardown-videon perusteella näissä molemmissa saattaa olla sisällä sama levy, Seagate Mobile HDD ST1000LM035, joka on SMR-tyyppinen. Manuaalin (https://www.seagate.com/content/dam/seagate/migrated-assets/www-content/product-content/seagate-laptop-fam/mobile-hdd/en-us/docs/100850135a.pdf) sivulla 6 on maininta ominaisuudesta "Shingled magnetic recording with perpendicular magnetic recording heads/media".
Näyttääkö smartctl levyn tarkemmat tiedot:
sudo apt install smartmontoolssudo smartctl -a /dev/sdb
-
sudo apt install smartmontools
$ sudo apt install smartmontools
Package smartmontools is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
-
Hmm, outoa. Tuo paketti on Ubuntun main-lähteessä, eli sen pitäisi kyllä olla aina saatavilla. Mitä apt update kertoo?
sudo apt update
-
Hmm, outoa. Tuo paketti on Ubuntun main-lähteessä, eli sen pitäisi kyllä olla aina saatavilla. Mitä apt update kertoo?
sudo apt update
Sama litanja tulee, ei löydy.
-
apt updaten ei kyllä pitäisi antaa mitään tuon tapaista vaan päivittää pakettilistat. Toimiiko apt-getillä:
sudo apt-get update
-
apt updaten ei kyllä pitäisi antaa mitään tuon tapaista vaan päivittää pakettilistat. Toimiiko apt-getillä:
sudo apt-get update
Aa, sori epäselvä vastaus. Siis apt udate toimii samoin apt-get update
Mutta sen jälkeen kun koittaa asentaa, niin sama virheilmoitus
$ sudo apt-get install smartmontools
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package smartmontools is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'smartmontools' has no installation candidate
$ sudo apt install smartmontools
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package smartmontools is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'smartmontools' has no installation candidate
-
Aa, sori epäselvä vastaus. Siis apt udate toimii samoin apt-get update
Apt updaten antama listaus kiinnostaisi kokonaisuudessaan. Siitä nähdään, mitkä ohjelmalähteet järjestelmään on konfiguroitu. Smartmontools-paketin puuttuminen on hyvin erikoista, ja viittaa siihen, että keskeinen main-lähde ei ole käytössä.
-
Apt updaten antama listaus kiinnostaisi kokonaisuudessaan. Siitä nähdään, mitkä ohjelmalähteet järjestelmään on konfiguroitu. Smartmontools-paketin puuttuminen on hyvin erikoista, ja viittaa siihen, että keskeinen main-lähde ei ole käytössä.
$ sudo apt update
[sudo] password for ...
Hit:1 http://fi.archive.ubuntu.com/ubuntu jammy InRelease
Get:2 http://fi.archive.ubuntu.com/ubuntu jammy-updates InRelease [128 kB]
Hit:3 https://download.docker.com/linux/ubuntu jammy InRelease
Get:4 http://security.ubuntu.com/ubuntu jammy-security InRelease [129 kB]
Get:5 http://fi.archive.ubuntu.com/ubuntu jammy-backports InRelease [127 kB]
Hit:6 https://packages.microsoft.com/repos/code stable InRelease
Hit:7 https://app.eduvpn.org/linux/v4/deb jammy InRelease
Get:8 http://fi.archive.ubuntu.com/ubuntu jammy-updates/restricted amd64 Packages [4 944 kB]
Get:9 http://security.ubuntu.com/ubuntu jammy-security/restricted amd64 DEP-11 Metadata [208 B]
Get:10 http://security.ubuntu.com/ubuntu jammy-security/universe amd64 DEP-11 Metadata [126 kB]
Get:11 http://security.ubuntu.com/ubuntu jammy-security/multiverse amd64 DEP-11 Metadata [208 B]
Get:12 http://fi.archive.ubuntu.com/ubuntu jammy-updates/restricted Translation-en [923 kB]
Get:13 http://fi.archive.ubuntu.com/ubuntu jammy-updates/restricted amd64 DEP-11 Metadata [212 B]
Get:14 http://fi.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 Packages [1 244 kB]
Get:15 http://fi.archive.ubuntu.com/ubuntu jammy-updates/universe i386 Packages [789 kB]
Get:16 http://fi.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 DEP-11 Metadata [360 kB]
Get:17 http://fi.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 c-n-f Metadata [30,0 kB]
Get:18 http://fi.archive.ubuntu.com/ubuntu jammy-updates/multiverse amd64 DEP-11 Metadata [940 B]
Get:19 http://fi.archive.ubuntu.com/ubuntu jammy-backports/restricted amd64 DEP-11 Metadata [212 B]
Get:20 http://fi.archive.ubuntu.com/ubuntu jammy-backports/universe amd64 DEP-11 Metadata [9 696 B]
Get:21 http://fi.archive.ubuntu.com/ubuntu jammy-backports/multiverse amd64 DEP-11 Metadata [212 B]
Hit:22 https://deb.nodesource.com/node_20.x nodistro InRelease
Fetched 8 812 kB in 2s (3 759 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
2 packages can be upgraded. Run 'apt list --upgradable' to see them.
-
Joo, eli lähde jammy-updates/main puuttuu kokonaan. Sen saa varmaankin kytkettyä päälle Ohjelmistot ja päivitykset -asetusohjelmalla, tai jos sieltä ei löydy, voit editoida suoraan /etc/apt/sources.list-tiedostoa. Jos päädyt editoimaan tiedostoa, listaa sen sisältö ensin tänne, niin katsotaan onko asetusrivi vain kommentoitu pois käytöstä.
cat /etc/apt/sources.list
-
Joo, eli lähde jammy-updates/main puuttuu kokonaan. Sen saa varmaankin kytkettyä päälle Ohjelmistot ja päivitykset -asetusohjelmalla...
Joo näin oli, kummallista.
San asennettua tuon smartmontools'n Laitan noista levyistä tietoa illemmalla.
-
sudo apt install smartmontoolssudo smartctl -a /dev/sdb
$ sudo smartctl -a /dev/sdb
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.0-157-generic] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
Read Device Identity failed: scsi error unsupported field in scsi command
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
-
OK, näemmä Seagaten ulkoisista levyistä on hankala saada SMART-tietoja Linuxissa, koska tarvittava rajapinta on kytketty vakiona pois käytöstä ajuritasolla: https://www.smartmontools.org/wiki/SAT-with-UAS-Linux
udevadm tai hdparm voisivat silti näyttää levyn tyypin ja sarjanumeron:
udevadm info --query=all --name=/dev/sdb
sudo hdparm -I /dev/sdb
-
udevadm tai hdparm voisivat silti näyttää levyn tyypin ja sarjanumeron:
udevadm info --query=all --name=/dev/sdb
Auttaako nämä?
N: sdb
S: disk/by-id/usb-Seagate_Basic_NT22J13L-0:0
E: ID_SERIAL=Seagate_Basic_NT22J13L-0:0
E: ID_SERIAL_SHORT=NT22J13L
Mallinro kotelosta STJL1000400
N: sdc
S: disk/by-id/usb-Seagate_Expansion+_NA8LYVZF-0:0
E: ID_SERIAL=Seagate_Expansion+_NA8LYVZF-0:0
E: ID_SERIAL_SHORT=NA8LYVZF
Mallinro kotelosta STKM1000400
-
No eipä tuossakaan näy oikein muuta kuin kotelon malli. Sarjanumeron perusteella Seagate toki tietää, mikä kovalevy siellä on sisällä, mutta tämä tieto ei taida olla julkisesti saatavilla.
Käytännössä kaikki Seagaten nykyiset 2,5" kovalevyt ovat kuitenkin SMR-levyjä, eli sen suhteen näissä ei varmaankaan ole eroa.
Tähän mennessä selvinneen perusteella veikkaisin, että hidas levy on jotenkin viallinen. Tiedostojärjestelmän vaihtamista NTFS:stä ext4:ksi voisi kyllä vielä kokeilla, etenkin jos levyä käytetään vain Linuxissa.
-
Tähän mennessä selvinneen perusteella veikkaisin, että hidas levy on jotenkin viallinen. Tiedostojärjestelmän vaihtamista NTFS:stä ext4:ksi voisi kyllä vielä kokeilla, etenkin jos levyä käytetään vain Linuxissa.
Ok, kiitos kuitenkin avusta. Pitää koittaa vaihtaa tuo tiedostojärjestelmä jahka jaksan kaiken data sieltä kopioida. :)
-
No eipä tuossakaan näy oikein muuta kuin kotelon malli. Sarjanumeron perusteella Seagate toki tietää, mikä kovalevy siellä on sisällä, mutta tämä tieto ei taida olla julkisesti saatavilla.
Entä /sys/class/-puu, löytyisikö sieltä? Esimerkiksi oman läppärini kovalevyn tietoja löydän komennoilla
cat /sys/class/nvme/nvme0/model
cat /sys/class/nvme/nvme0/serial jne.
-
Entä /sys/class/-puu, löytyisikö sieltä? Esimerkiksi oman läppärini kovalevyn tietoja löydän komennoilla
cat /sys/class/nvme/nvme0/model
cat /sys/class/nvme/nvme0/serial jne.
[/quote]Noista USB-asemista ei oikein meinaa tulla läpi se oikea aseman sisältö.