Másolás LAN-on, sávszélesség korlátozással?

Miert kell ehhez a tc doksija? Tenyleg nem ertem a problemadat:

Én meg azt nem értem, hogy mit nem lehet ezen érteni:
- a szkripted vajon minden tőlem a szerver felé menő forgalmat sávkorlátozni fog?
- ha igen, akkor hogyan szorítsam a sávkorlátozást csak arra az egy fájlmásolási műveletre?

Hogyan tudnék ezekre a kérdésekre a tc ismerete nélkül válaszolni????

Márpedig nem szándékozom a tőlem a szerver felé irányuló teljes, (amúgy is lassú) forgalmat a másolás miatt fél napokra tovább sávkorlátozni, mert azzal meg magamat szívatnám meg, de nagyon.

A bzip-es megoldás viszont egyszerű, és eleve csak arra az egy másolási műveletre vonatkozik.
Ráadásul pontosan ugyanakkora sávszélességet hagy meg nekem a szűk hálózati keresztmetszeten át (a másolási művelet által lefoglalton felül), mint másoknak, és a nice miatt még észrevehetetlen is.
Plusz megvan az az előnye, hogy egyetlen másolási művelet elvégzéséhez nem kell traffic shaping szakértővé válnom.

A konkrét esetben a sok hátrány mellett a tc alkalmazásának egyetlen előnye az lenne, hogy nem dolgoznak a procik. Hát dolgozzanak. Azért vannak. Egy félnapos, nice-olt, 40%-os processzor használat nem visz egy gépet padlóra, főleg, hogy azon kívül szinte semmi dolga egész nap.

Némely magát szakértőnek tartó személy egyébként csodálkozna rajta, hány helyen használják a tömörítést a szűk sávszélesség áthidalására.

És nem csak szakbarbárok.

vilagosan leirtak h mit kell csinalni

Öreg, amíg én nem mondom meg neked, hogy mit kell csinálnod (pedig most már volna rá ötletem), addig te se utasítgass.

Mert csak én vagyok az összes információ birtokában ahhoz, hogy eldöntsem mit akarok elérni, és milyen áron, és nem te.

Hogy képben legyél: a célgép egy fájlszerver, ahol a hálózat sebessége és a lemez I/O műveletek jelentik a szűk keresztmetszetet, nem pedig a CPU használat, ami szinte egész nap, folyamatosan 1% alatt marad.

Ezért ha én a CPU-t a másolás alatt a szerveren 40%-ig megdolgoztatom, az az égvilágon senki számára semmilyen észrevehető hatással nem jár.

A LAN-unkon van egy gateway, amin kb. 3 óra alatt tudok átküldeni egy dvd-nyi adatot, de azonközben mindenki aki azon a gateway-en halad át szentségel, mert nekik már nem jut sávszélesség; az adatbázisaik belassulnak, stb.

Valahogy sávszélesség korlátozással kellene átküldenem az adatot, de nem tudom, hogyan.

Idefelé még csak-csak megy a dolog az scp-vel:
mkfifo p1.iso
growisofs -dvd-compat -Z /dev/hdb=p1.iso & scp -l 4500 -oProtocol=1 masikgep:/path/to/iso.iso p1.iso

A fenti paranccsal egy másik szerveren lévő dvd iso-ból "röptében" dvd-t írok, úgy, hogy közben az én gépemen nem keletkezik több GByte-os iso fájl (nincs helyem), és a sávszélesség is korlátozva van.

De hogy csináljam ezt visszafelé?

Merthogy ez az iso fájl készítő parancs már nem működik:
dd if=/dev/dvdrecorder of=p1.iso & scp -l 4500 -oProtocol=1 p1.iso masikgep:/path/to/iso.iso

A probléma az, hogy a jelenlegi tudásom szerint csak az scp-vel tudok a másolás közben sávszélességet korlátozni; az scp pedig ugyan hajlandó egy fifo-ba másolni, de nem hajlandó a másolandókat egy fifo-ból venni, és tudomásom szerint a "standard input"-ról se.

Mi lehet a megoldás?

Aha. Azaz, ha jól értem, akkor a tc segítségével korlátozni tudnám a tőlem a szervert felé irányuló forgalom sávszélességét. Azaz, tetszőleges másoló eszköz mellett működne a sávkorlátozás.

Jól hangzik, de a vonatkozó tc parancsok egyelőre elég kínainak tűnnek :cry:

Beleolvastam még egyszer a tc dokuba,brrrrrrrrrr...

Még hál istennek, hogy közben rájöttem, van egyszerűbb megoldás: tömöríteni kell a bzip2-vel a másolt adatot.
A bzip2 olyan tetü lassú, hogy önmagában előállítja a kívánt sávszélesség korlátozást.
Úgyhogy most így írok a gépemről dvd-ről iso-t közvetlenül a "foo" szerverre:

dd if=/dev/hdb | bzip2 | ssh -1 -l myusername foo "bunzip2 > /path/to/dvd.iso"

Ez ugyan az én esetemben csak a kívánt sávszélnek kb. a felével másol, de a veszteség nagyrészét visszanyerem a tömörítés miatt. :)

Ennel megoldassal mindket gepen maxon hajtod a processzort!

Csak az én gépemen megy maxon, mivel az végzi a nagyságrenddel nagyobb munkát: a tömörítést. Természetesen ellenőriztem is: a szerveren a processzor használat az ssh-val együtt is 40% alatt marad.

De még az sem lenne zavaró, ha ott is 100% lenne a processzor használat: arra való a nice, hogy az ilyen eseteket menedzselje.

Globálisan szemlélve a megoldás még logikus is: nem (vagy nem csak) alkalmazkodik a szűk keresztmetszethez, hanem kitágítja azt, az egyébként veszendőbe menő processzor idő árán (mert ugye máskor mindkét processzor terhelése folyamatosan, tartósan 1% alatt van - tiszta pénzkidobás).

A tc sem komplikalt, csak siman alkalmazd azt a semat amit a szkriptbe megirtam.

Csak olyasmit alkalmazok, amit értek. A tc dokujából viszont fél óra alatt még csak kapisgálni sem kezdtem a koncepciót - még a mintapéldák alapján se - ami pedig még soha sem fordult elő velem.
Azért köszi a tippet; elismerem, hogy az esetek többségében az általad javasolt megoldás a célravezető; csak éppen a jelen konkrét esetben az ágyúval verébre lövöldözés tipikus esete lenne.