Metka vika Kubuntussa usb-muistien kanssa.

[JaniAlander]

Kopioi tiedosto ntfs formatoidulle tikulle, ihmettele kun kopionti vaikuttaisi sujuvan todella nopsasti, vilkaise tiedostonhallinnalla onko tiedosto tikulla. Juu on. Unmounttaa tikku, ja mounttaa taas irroittamatta tikkua fyysisesti välillä. Edelleenkin tiedosto näyttäis olevan tikulla. Kokeilet avata sen ja aukeaakin oikein. Usko asiaan, ja unmounttaa tikku ja kiinnitä toiseen koneeseen siirtääksesi tiedoston sinne. JA mitäs kummaa, tiedosto, joko ei ole tikulla lainkaan tai siitä on puolittain siirretty korruptoitu versio. Toista homma. Edelleen sama juttu. Muuta nimeä varmasti ntfs yhteensopivaksi. Sama juttu. Kopioi tiedosto, jätä tikku kiinni koneeseen. Ja jostain *piip* syystä VASTA TÄLLÄ tavalla käyttis aikuisen oikeasti KOPIOI sen tiedoston fyysisesti kokonaisuudessaan sinne TIKULLE.

Ja kikkaa on kokeiltu niin graafisella tiedostonhallinnalla kuin komentorivilläkin. Ja unmounttaus suoritettu sillä "irroita turvallisesti" käskyllä. Juu ymmärrän, että tiedoston kopiointia odotutetaan aikansa, mutta mikä ihmeen idea on siinä, että edes se unmounttauskäsky ei vaikuta saavan aikaiseksi toimenpiteen asiallista suoritusta.

[nm]

Ja kikkaa on kokeiltu niin graafisella tiedostonhallinnalla kuin komentorivilläkin. Ja unmounttaus suoritettu sillä "irroita turvallisesti" käskyllä. Juu ymmärrän, että tiedoston kopiointia odotutetaan aikansa, mutta mikä ihmeen idea on siinä, että edes se unmounttauskäsky ei vaikuta saavan aikaiseksi toimenpiteen asiallista suoritusta.

Ainakin päätteessä ajetun umountin pitäisi jäädä odottamaan, että kopiointi on valmis. Jos näin ei tapahdu, käyttämässäsi NTFS-3G:n versiossa on bugi. Mikä Kubuntun versio on kyseessä ja ovatko päivitykset ajan tasalla?

Esimerkki omassa Ubuntu 12.04:ssäni:

nm@i:~$ cp isotiedosto /media/tikku/
nm@i:~$ time sudo umount /media/tikku

real   0m21.048s
user   0m0.004s
sys   0m0.088s

Tässä umountin suoritus kestää siis niin kauan kuin tiedoston kopiointi vaatii. Graafisella puolella irrotettaessa Nautilus näyttää latausikkunan, joka kertoo, että tiedostoja siirretään vielä.

[JaniAlander]

Hiljakkoin asennettu 12.04 64-bit, ja päivitykset ovat ajantasalla. Täähän ei puhdas Kubuntu ole, vaan löytyy myös se normi Unity, ja nautiluksen kanssa homma näyttäis pelaavan oikein. Ilmeisesti Dolphinin irroita turvallisesti komento ei toimi oikein.

[nm]

Tämä bugiraportti viittaa samanlaisiin ongelmiin:
https://bugs.kde.org/show_bug.cgi?id=162211

Keskustelua KDE:n foorumilla:
http://forum.kde.org/viewtopic.php?f=22&t=98541

Keskustelua Redditissä:
http://www.reddit.com/r/linux/comments/1nvho0/warning_theres_a_horrible_bug_in_kde_that_doesnt/

Nopeasti selattuna kenelläkään ei ole varmaa tietoa, missä vika varsinaisesti sijaitsee.

[amateur]

Vika kuulosti niin tutulta etten hämmästynyt lukiessani tätä:

"For what it's worth: Mac OS X's Finder and Windows 7 Explorer suffer the same problem. I hope it is fixed soon so we are ahead of those two ;-)"

Lisätään listaan Mac Os 9, w95, w98, w2000 ja XP.

Kaikissa sama perusvika, käyttis "näyttää" että tiedostonsiirto on tehty,
mutta jos on ledillinen tikku, huomaa sen itsekin että ledi vilkkuu siellä vielä pitkäänkin.

Ohjelmointipuolesta en tiedä mitään, mutta ensimmäiseksi tulee mieleen että käyttisten
tekijät ovat jättäneet koko tämän homman "vähän kesken":
Kun kopioi/siirto - komento on jollain tavalla mennyt RAMmissa tiettyyn pisteeseen,
graafiset edistyspalkit näyttävät 100%ia ja usein näin katoavat ruudulta.
Ne eivät siis itseasiassa kerro ollenkaan sitä, mitä TIKULLA (tai ulkoisella USB-kovolla) tapahtuu.

Isojen tiedostojen siirtämisessä olen havainnut tätä myös verkossa,
käyttis sanoo toisella koneella että siirretty on, mutta koneiden verkkoledit vilkkuvat
ja vastaanottavan koneen kovalevy vilkkuu joskus pitkäänkin.

Tätäkin ihmettelin viimeksi viime viikolla, lähettävässä koneessa 8 gigaa RAMmia,
vastaanottajalla 1 giga... juu, älä luule että se on siellä samalla sekunnilla kun se
lähettävä kone kertoo niin...

Eilen siirsin 2,1 gigan videota kovolta tikulle, oli KDEn alapalkin se ilmoituslätkä auki
josta näkyi edistyminen ja siirtonopeus. Se saavutti 100%ia, ja siirtonopeus hiljeni.
Meinasin napata tikun irti, mutta joku vaistonpätkä sanoi että älä. Siis odotin.
Meni yli minuutti, vasta sitten KDE antoi ilmoituksen että "kopiointi suoritettu".

Jos tämä bugi on ollut näinkin pitkään ja joka puolella, pitäisi nuo progressiomittarit
kääntää lukemaan sitä, mitä siellä itsessään tikulla varsinaisesti tapahtuu.
Outoa myös verkkopuolella ettei sieltä tule "kuittausta vastaanotosta".

Joskus on tapahtunut myös sitä, että kun on ladannut netistä jotain selaimen kautta,
ja vaikka selain näyttää 100% ladattu, ei se viimeinen bitti välttämättä olekaan vielä kovalevylle
kirjoitettu. Ihanaa kun kiireessä alkaa siirtää sitä "muka valmista" ja saakin sitten ilmoituksen
"tiedoston siirto epäonnistui".

Jotenkin tulee mieleen että käyttiksen pitäisi tehdä tuo "100% valmis" -kuittaus
vasta sitten kun se on sinne kohteena olevaan mediaan kirjoitettu.

Servereitten kanssa siihen "vaan tottui", että odotapa rauhassa minuutti tai pari,
kyllä se sinne sitten kirjoittuu, vaikka tiedostonhallinnassa näkyikin jo.

Onhan se tässä valossa outoa että CDn poltto-ohjelmat ovat asiassa kehityksen kärjessä,
"kirjoitus onnistui" -lätkä tulee vasta sitten kun se viimeinenkin bitti varmasti on siellä lätyllä.

[JaniAlander]

Tää eroaa sillä tapaa amateurin esittämästä kuviosta, että vaikka sitten kopioinnin jälkeen käsket irrottaa tikun turvallisesti ja tikku on irroitettavissa käyttiksen mukaan, ei se oikeasti ole. Dataa on vielä siirtymättä. Käyttis olennaisesti siis valehtelee käyttäjälle. Ja hauskasti tosiaan ns. "onnistuneen" kopioinnin jälkeen voit jopa avata esim. kopioidun elokuvatiedoston määränpäästä ja se näyttäisi toimivan. Vitsikkäästi ilmeisesti se luetaankin jostain puskurista. Käyttis valehtelee siis jälleen.  Komentoriviltä annettu umount käsky tuntuisi pelittävän oikein. Tänään testasin ja se näyttäisi irroittavan vasta kun kirjoitus on OIKEASTI tehty.

Jos nyt jostain kohtaa vaikkapa Windowsin toiminnasta pitäisi ottaa mallia niin: Kun kopsaa sillä tikulle, ja käskee irroittaa turvallisesti, niin Windows kyllä kertoo milloin toimenpiteet ovat loppu, ja tavara oikeasti siellä tikulla, ja saako sen tikun nyt sitten irroittaa.

nm:n linkit olivat kiintoisia, ja on kyllä tutun oloista toimintaa.

[amateur]

Ok, toi on selkeä bugi munkin mielestä.

Aloitin vaan hölinän näin yleisellä tasolla, koska toi on aika hölmöä puuhaa.
Kyllä käyttöjärjestelmän pitäis mun mielestä kertoa koska joku tiedosto
on Ihan Oikeasti Perillä, eikä vielä jossain swapissa tai kovon cachessa
etsimässä oikeata laskeutumissektoria ja blokkia...

[JaniAlander]

Ok, toi on selkeä bugi munkin mielestä.

Aloitin vaan hölinän näin yleisellä tasolla, koska toi on aika hölmöä puuhaa.
Kyllä käyttöjärjestelmän pitäis mun mielestä kertoa koska joku tiedosto
on Ihan Oikeasti Perillä, eikä vielä jossain swapissa tai kovon cachessa
etsimässä oikeata laskeutumissektoria ja blokkia...

Juu, käyttäjän harhaanjohtaminen on minusta todellinen kardinaalimoka, tekee sen sitten mikä käyttis hyvänsä. Tuntuisi olevan paremminkin KDE:n bugi kuin Linuxin itsensä, olen saman vian onnistunut toistamaan PC-BSD:llä, joka ei tosiaankaan Linux-käyttis ole, mutta käyttää KDE:tä käyttöliittymänään.

[jekku]

Onko vika sitten käyttiksessä vai tuossa kludgessa filesysteemissä

Juurikin tänään tein saman havainnon. Melko iso tiedosto (1.4G) tuntui menevän nopeasti.
Mutta jostain jäänyt selkäyimeen varmistusloitsu:

Koodia: [Valitse]


sudo sync


Ja se sitten kestikin hiukan...

Vielä en ole ko. tiedostoa avannut, kunhan uteliaisuuksissani tarkistin.
Ja ainakin

Koodia: [Valitse]

unzip file.zip
vaikutti tyytyväiseltä.

[nm]

Onko vika sitten käyttiksessä vai tuossa kludgessa filesysteemissä

Ei kummassakaan vaan jossain KDE:n komponentissa. Käyttäjä irrottaa tiedostojärjestelmän, mutta käyttöliittymä ei ilmaise millään tavalla, että puskurien siirto levylle on kesken.

[jekku]

Onko vika sitten käyttiksessä vai tuossa kludgessa filesysteemissä

Ei kummassakaan vaan jossain KDE:n komponentissa. Käyttäjä irrottaa tiedostojärjestelmän, mutta käyttöliittymä ei ilmaise millään tavalla, että puskurien siirto levylle on kesken.

No minulla ei ole (tietääkseni) KDE:n komponentti mukana tilanteessa kun sanon

Koodia: [Valitse]


time cp file.zip /media/SD8/FI/.


Ilmeisesti tuo time on tyytyväinen siihen kun data on puskureissa ja vapauttaa komentorivin muihin puuhiin.
En huomannut kokeilla miten mv olisi toiminut, se kai odottaa jotain kuittausta miten onnistui?

[nm]

No minulla ei ole (tietääkseni) KDE:n komponentti mukana tilanteessa kun sanon

Koodia: [Valitse]


time cp file.zip /media/SD8/FI/.


Ilmeisesti tuo time on tyytyväinen siihen kun data on puskureissa ja vapauttaa komentorivin muihin puuhiin.

Kyllä, mutta tämä ei ole varsinaisesti mikään ongelma niin kauan kuin tiedostojärjestelmä on liitettynä. Tällainen puskurointi on olennainen osa levyoperaatioiden nopeuttamista nykyisissä käyttöjärjestelmissä.

Tämä KDE:n bugi liittyy nimenomaan tiedostojärjestelmän irrottamiseen. Päätteessä umount ei palauta komentokehotetta ennen kuin data on levyllä. Nautilus näyttää ikkunan, joka ilmaisee, että siirto on kesken. KDE/Dolphin sen sijaan ei anna tällaista palautetta vaan vaikuttaa siltä, että kaikki on valmista ja tikun voi ottaa irti koneesta.

[amateur]

Nautilus näyttää ikkunan, joka ilmaisee, että siirto on kesken. KDE/Dolphin sen sijaan ei anna tällaista palautetta vaan vaikuttaa siltä, että kaikki on valmista ja tikun voi ottaa irti koneesta.

Hyvä tietää siis, mulla KDE näyttää sen "notification" siinä alapalkissa, joten pidän sen näkyvissä kunnes tulee ilmoitus että "copying finished" (pyöritän sitä englanninkielisenä).

Tässä asiassa olis vielä isompi remontin paikka, nykyään kun ihmiset enemmän ja enemmän siirtelee kamaa puhelin-tabletti-ties minne jne.

[JaniAlander]

Siinäpä se onkin kun se notification antaa ymmärtää myöskin että tiedosto on siirretty. En minä nyt niin hölmö olisi, että antaisin käskyn irroittaa tikku ennen kuin sanotaan että operaatio on valmis.

[amateur]

Ahaa... ettei siihenkään vielä voi luottaa?

Se ensimmäinen notification, jossa näkyy se edistyspalkki ja siirtonopeus,
ja sitten myöhemmin se toinen joka kertoo että se on siirretty,
ja tiedosto ei vieläkään ole siirtynyt?

Ei vaikutakaan enää ihan miltään pikkubugilta, aika olennaiselta...

Tähän mennessä mä oon sokeasti luottanut siihen että "copying finished"
tarkoittaa sitä ihan oikeasti...

Pitäiskö tässä seuraavan Mintin kanssa vaihtaa työpöytää...?
Wintoosa kävi verenpaineelle kun aina piti klikkailla ok ja oletkovarmaa,
muttei tästäkään kicksejä saa jos täytyy terminaalin kanssa perässä juosta...

[nm]

Ei vaikutakaan enää ihan miltään pikkubugilta, aika olennaiselta...

Jep.

Tähän mennessä mä oon sokeasti luottanut siihen että "copying finished"
tarkoittaa sitä ihan oikeasti...

Silloin osa datasta on vielä matkalla perille muistipuskureissa. Käyttöjärjestelmä ei anna ohjelmille suoraa tietoa siitä, mitkä yksittäiset operaatiot tai tiedostot ovat oikeasti valmiita. Muistipuskurin tyhjentämiseen voi mennä vielä hyvinkin pitkä aika, jos kohdelevy on hidas.

Varmuuden saa vasta sync-järjestelmäkutsulla tai irrotettaessa levyä (kunhan käyttöliittymä ilmoittaa irrotuksen olevan kesken), jolloin kaikki levyllä olevien tiedostojärjestelmien puskurit kirjoitetaan levylle. Silloinkin on syytä odottaa vielä muutama sekunti ennen kuin repäisee tikun irti:

man 8 sync

On  Linux,  sync  is  only  guaranteed to schedule the dirty blocks for
writing; it can actually take a short time before all  the  blocks  are
finally  written.   The  reboot  and halt commands take this into
account by sleeping for a few seconds after calling sync(2)

[JaniAlander]

Jep itse olen sen vaikutelman saanut, että tuo kopiointi ilmoitetaan valmiiksi jahka koko tiedosto on luettu, ei niinkään kirjoitettu.

[Postimies]

Samoja huomioita varsinkin isojen tiedostojen kanssa. Esim. TV-tallenteet tikulle tiedosto kerrallaan. Jos esim. kopioi monta esim 5 kpl noin 1G kokoisia tiedostoja niin kopiointi kestää minulla ikuisuuden. Voi käydä vaikka kaupassa. Parempi vain odottaa että tikun ledi lopettaa joskus vilkuntansa.