mv komennon hitaus

[HACY]

Käytössä Ubuntu 10.10. Päivitetty ajan tasalle viime viikonloppuna.

Olen siirtämässä kasan isoja tiedostoja omasta kotihakemistostani verkkolevylle. Verkkolevy (Netgear/Infrant RadyNAS NV+) käyttää smb jakoa ja olen tuplaklikkaamalla Nautiluksessa mountannut sen ja se näyttää ilmestyneen ~/.gvfs/.../ hakemistoon.

Nyt jos Nautiluksessa valitsen tiedostokasan, sanon niille "Cut" menen verkkolevylle ja siellä "Paste" niin tiedostot siirtyvät ja verkkoliikennettä monitoroidessassa näkyy liikenteenä tasaisesti n. 10MB/s (gigabitin verkko)

Nyt jos terminaalissa sanon mv blaa* ~/.gvfs/.../ niin kaikki tiedostot siirtyvät (edit: oli: kopioituvat) samaan paikkaan, mutta turkasen paljon hitaammin ja verkkoliikennettä monitoroidessa näkyy vaivainen, mutta tasainen n. 2MB/s nopeus ja paljon matalampi palkki. Sama juttu cp komennolla.

Miten voi mv komento olla siirtonopeudeltaan verkkoon vain 20% graafisen copypasten tehosta

  .

[Ganymedes]

En tiedä, mutta onko rsync myös hidas? ... ehkä parempi komento muutoinkin ...

Esim:

rsync -urv /home/hakemisto/  /mnt/joku_mountattu_hakemisto_verkossa/

( Edellytys siis on että jälkimmäisestä paikasta löytyy hakemisto, joka on Sambaa varten mountattu ja siihen on kirjoitusoikeudet. )

rsync toimii usealla prosessilla yhtaikaa, esim. se tekee tyhjiä hakemistoja kohteeseen "etuajassa" samalla kun tiedostoja kopioidaan - kerron koska tällainen käytös poikkeaa suoraviivaisimmista komennoista.

[HACY]

En tiedä, mutta onko rsync myös hidas? ...

Mielenkiintoinen ehdotus. Olin jumiutunut ajattelemaan rsyncin käyttöä vain kahden samanlaisen hakemistorakenteen synkronointiin kahdessa eri koneessa, mutta mikä ettei. Pitää kokeilla ensi viikolla, kun olen fyysisesti kyseisen koneen ääressä.

Jos jollain on lisätietoa mitä menetelmiä Ubuntun Nautilus käyttää tiedostojen kopiointiin tai siirtoon ja miten niitä samoja menetelmiä voisi kutsua komentoriviltä ssh yhteyden yli ilman X11 yhteyttä, niin se myös auttaisi suuresti.

  .

[Ganymedes]

Itse taas ajaudun useissa isommissa kopiointitilanteissa synkronointiin ... ehkä tämä ajattelu tulee enemmän Windows-maailmasta, jossa verkon yli kopiointi käyttäen interaktiivista tapaa on varsin epäluotettavaa: kopiointi voi epäonnistua ilman, että käyttäjä tietää sitä. Ratkaisu siellä on robocopy.

Kopiointi voi yleisesti ottaen päätyä synkrointitarpeeseen varsin monesta syystä johtuen: tietoverkon epäluotettavuus, median epäluotettavuus (kuten dvd:t), tietoverkon pätkiminen (kuten isoissa tietoverkoissa helposti käy), tietoverkon säännölliset alasajot (kuten pitkissä kopioinneissa), virheet lähteessä tai kohteessa (kuten lähteen epästabiilisuus tai tiedostojärjestelmän virheet), tarve katkaista kopiointi sen kestäessä "liian" kauan, tilan loppuminen kohteessa. Tietysti vakaassa kotiverkossa näitä ongelmia ei "pitäisi" yleensä olla, mutta eihän vara venettä kaada 

[HACY]

rsync on yhtä hidas. 1,7 - 2,1 MiB/s kertoo System Monitor / Resources.

  .

[Ganymedes]

Vertailun vuoksi, paraikaa menossa oleva iso kopiointi:

- tiedostokoko: 2-10 MB
- serveri: Ubuntu 8.10 64-bit
- kohde: työasema 10.10 64-bit
- verkko: 100 Mbit/s
- välissä on vain halpiskytkin, ei esim. ns. palomuuripurkkia
- ylimääräisiä rajoittavia ohjelmia, kuten palomuureja tai virusskannereita ei ole (miten muuten sulla?)

Kopiointi rsyncillä sujuu suh.koht. tasaisena 5.5-6 MB/s virtana. Tämä lienee lähellä maksimia mikä käytännössä näillä koneilla menee läpi.

[HACY]

Vertailun vuoksi, ...

Joo, en epäile yhtään etteikö jollain toisella kokoonpanolla voisi olla tehokkaampikin. Se absoluuttinen nopeus nyt ei ollut se pointti, vaan nopeusero, kun:
1. lähdekone sama kummassakin tapauksessa.
2. kohdekone sama kummassakin tapauksessa,
3. mounttaus sama, eli tuplaklikkaamalla Nautiluksessa
4. verkko sama kummassakin tapauksessa.
5. tiedostot samat kummassakin tapauksessa.
6a. graafisesti cut&paste, siirtonopeus n. 10 MB/s
6b. mv tai rsync komento, siirtonopeus n. 2 MB/s

Eron huomaa kopiointiajassa, System Monitorin ilmoittamassa siirtonopeudessa sekä saman ohjelman palkin korkeudessa.

Tuo kolmonen minua epäilyttää, eli jos Nautiluksen gvfs/fuse tiedostojärjestelmä jotenkin sotkee suoraa mv-komentoa.

  .

[Ganymedes]

...
3. mounttaus sama, eli tuplaklikkaamalla Nautiluksessa
...
Tuo kolmonen minua epäilyttää, eli jos Nautiluksen gvfs/fuse tiedostojärjestelmä jotenkin sotkee suoraa mv-komentoa.

No joo, kyllä. Ei tuossa minun järjestelmässäni muutoin ole mitään erikoista, verkkokin on hitaampi. Pitäisi toimia heittämällä vähintäin samalla nopeudella kuin mitä minulla on - samankokoisilla tiedostoilla.

Minä käytän mount-komentoa ja smbfs ...

... komentoa, joka on jotain tällaista:

sudo mount -t smbfs -o codepage=cp850,iocharset=utf8,username=user,password=joku //192.168.10.10/serverin_jako /mnt/mountti_paikka

Taitaa olla tuo "codepage" ihan turha, valittaa siitä, mutta toimii. "/mnt/mountti_paikka" pitää olla olemassa ja "smbfs" pitää olla installoitu.

Periaatteessa kai pitäisi käyttää cifs:iä, mutta en ole perehtynyt siihen ja smbfs tuntuu vielä pelaavan sekin. Tietysti jos joku ON perehtynyt, niin voisi vaikka kertoa mitä tuo on cifs:llä - jos se on parempi?

[Ganymedes]

Pikainen lisätesti näyttää, että kun lisää toisen rsync -tehtävän, joka kirjoittaa eri levylle, niin kokonaisliikenteen saa kasvamaan yli 8 MB/s:n ja kolmannella tehtävällä vielä siitäkin. Kolmannella tullee jo verkon todellinen maksimikapasiteetti vastaan.

Tämä on kyllä tyypillistä, että yhdellä tehtävällä ei saa verkon kuormitusta maksimiin - mutta voi olla että rsync:ssä tätä voi virittää - ei ole ollut tarpeen tutustua tähän, koska rsync:llä yleensä pärjää näinkin, koska ainahan voi keskeyttää ja jatkaa myöhemminkin.

Jostain syystä näyttää siltä, että esim. Windows 7/robocopy -yhdistelmä toimii huomattavasti hitaammin kuin XP:llä - ehkä tietoinen valinta, jotta tällä työkalulla ei saa verkkoa tukkoon liian helposti. Tämä nyt ei suoranaisesti kuulu tähän, mutta ilmiöt ovat samankaltaisia.

[HACY]

Minä käytän mount-komentoa ja smbfs ...

Tuossa se sitten oli. Eli kun (loppujenlopuksi smbfs:n asennuksen jälkeen) sain mountattua hakemiston komentoriviltä (kiitti esimerkkisyntaksista), niin cp komento alkoi siirtää sen saman 10 MB/s minkä Nautiluskin siirtää.

Se mounttaus vaatii vielä hieman säätämistä, sillä minulla normikäyttäjänä ei ollutkaan kirjoitusoikeutta omaan hakemistooni, eli jouduin testaamaan tuon siirron 'sudo cp ...' Eiköhän se kuitenkin osoita missä vika oli.

Kiitti, nyt ei jaksa enempää säätää, mutta asia selvisi. Huomenna jatkan työpäivän jälkeen - ehkä. (Kokeilen varmaan ensin rivin lisäämistä fstabiin user option kanssa. niin että itse mounttauksen yhteydessä en tarvitse sudo'a.)

  .

[Ganymedes]

Hyvä että selvisi. 

[HACY]

Hyvä että selvisi. 

Kiitos avusta ja sparrauksesta.   

[_Pete_]

Itsellä ollut samanlaisia kokemuksia/nopeusongelmia. Nyt kun himan tutkin niin smbfs käyttää loppupeleissä
cifs. Eli se että fstab muuttaa smbfs/cifs ei pitäisi mitään vaikuttaa asiaan.

mount.smbfs on scripti joka tulkitsee parametrit ja sitten käyttää mount.cifs komentoa.

[HACY]

Eli testattu ja homma todistetusti toimii ja nopeus on samaa luokkaa.

Tein hakemiston mounttauspisteeksi:
mkdir ~/srv_share

Sitten lisäsin (roottina) rivin /etc/fstab tiedoston loppuun
//192.168.xx.xx/share /home/user/srv_share smbfs noauto,user,username=user 0 0

ja sen jälkeen komento 'mount srv_share' kysyi salasanan ja mounttasi hakemiston näkyväksi ja mv komentokin siirsi dataa ihan kiitettävästi.

Pikku kauneusvirhe on, että umount vaatii sudo'n eteen. Normaalikäyttäjänä se ei tunnu toimivan.

  .

[Ganymedes]

Samba mountit ajan yleensä komentoriviltä enkä fstabin avulla. Komennot säilyvät komentopuskurissa, joten toimii ihan kätevästi näinkin. Eri levyjä tai eri jakoja varten on tietysti omat komentonsa. Varsinaista "umount:ia" ei tarvitse tällöin tehdä ollenkaan - häviävät kyllä alasajossa.

Interaktiivista käyttöä varten teen Bookmark:it valmiiksi serverin levyille, joten niihin pääsee "Places" menun alta klikkaamalla automaattisesti.

Tiedostoihin ja Sambaan annetut oikeudet pitää tietysti olla kunnossa joka tapauksessa - mutta se on oma lukunsa.

[_Pete_]

Eli testattu ja homma todistetusti toimii ja nopeus on samaa luokkaa.

Totta tosiaan testasin sitten itsekkin, kun muuntaa cifs -> smbfs nopeus on kertaluokkaa suurempi eli
sama kuin jos gnome:sta määrittelee network place:n kyseiseen jakoon... (linux) maailma on täynnä
ihmeitä!

[HACY]

paitsi että...   

kun nyt olen saanut mountattua fstabin avulla tuon ulkoisen smb sharen, niin nyt Nautilus näyttää siirtävän sinne hitaa(hko)sti! Näytti olevan n. 4MiB/s, eli

1. Mounttaus Nautiluksesta tuplaklikkauksella, Siirto Cut&Paste'lla Nautiluksesta, 10 MiB/s
2. Mounttaus Nautiluksesta tuplaklikkauksella, Siirto mv-komennolla, 2 MiB/s
3. Mounttaus komentoriviltä, Siirto Cut&Paste'lla Nautiluksesta, 4 MiB/s
4. Mounttaus komentoriviltä, Siirto mv-komennolla, 10 MiB/s

 

  .

[Ganymedes]

paitsi että...   

kun nyt olen saanut mountattua fstabin avulla tuon ulkoisen smb sharen, niin nyt Nautilus näyttää siirtävän sinne hitaa(hko)sti! Näytti olevan n. 4MiB/s, eli

1. Mounttaus Nautiluksesta tuplaklikkauksella, Siirto Cut&Paste'lla Nautiluksesta, 10 MiB/s
2. Mounttaus Nautiluksesta tuplaklikkauksella, Siirto mv-komennolla, 2 MiB/s
3. Mounttaus komentoriviltä, Siirto Cut&Paste'lla Nautiluksesta, 4 MiB/s
4. Mounttaus komentoriviltä, Siirto mv-komennolla, 10 MiB/s
 

Ehkä huomasit, mutta tavalla jonka kuvasin yllä tuota ongelmaa ei koskaan tule.

a) Silloin kun haluaa vain nopeasti ja interaktiivisesti käyttää verkkolevyä, Nautiluksen Bookmarkit käyvät siihen hyvin.

b) Silloin kun haluaa tehdä massiivisia kopiointeja, niin komentorivin "mount" ja "rsync" toimivat hyvin.

Molemmat tavat voivat sinänsä olla käytössä samanaikaisestikin ilman ongelmia.

[HACY]

Huomasin, Tuo edellä oleva oli lista saaduista mittaustuloksista ja sen perusteella on pakko päätyä hyvin samantapaisiin johtopäätöksiin ja käytäntöihin.

  .