Dotaz: Poškození dat zaslaných přes netcat. Co s tím?

[JanM]

Dobré pozdní odpoledne,

marně bojuji s následujícím problémem:

pepa@local$ ssh -c blowfish ${USER}@${REMOTE} "sudo zfs send ${MPOOL}@snap | \
            netcat -c ${LOCAL} 8023" | netcat -w 30 -l -p 8023 ${REMOTE} | \
            zfs receive -uvFd backup

Celkem to funguje, ale občas ne a na konci přenosu to vyhodí:

read(net): Connection reset by peer

a zfs receive oznámí chybu ohledně poškozeného streamu.

Nefunguje to hlavně u hodně velkého objemu dat (300+ GB). Testování je poněkud náročné, protože to při rychlosti 20 MB/s trvá půl dne.

Pokud netcat vyhodím a proháním to jen přes SSH, tak m'kay, jenže to poněkud hodně vytěžuje Intel Atom na $LOCAL.

Říkám si, jestli není problém se streamem na začátku spojení - tj. trochu dat se ztratí než netcat naváže spojení - či na jeho konci, tj. netcat na serveru ($LOCAL) se ukončí dříve než do pipe pošle všechna data.

Trochu krkolomně by se to možná dalo obejít změnou posloupnosti příkazů: nejprve spustit netcat -l na $LOCAL, potom netcat (bez -c) na $REMOTE, přidat nějaký timeout či kontrolu, že už se žádná data nezapisují, a nakonec zabít jeden z těch netcatů, druhý se ukončí automaticky. Ale zatím se mi to moc nedaří naskriptovat :-/

Nesetkal jste se někdo s něčím podobným?

Odpovědi

[NN]

Pokud jsem to pochopil, tak na vzdalenem serveru nacpes data do netcatu:

ssh -c blowfish ${USER}@${REMOTE} "sudo zfs send ${MPOOL}@snap | netcat -c ${LOCAL} 8023"

a potom je lokalne pres druhy netcat vyzvednes a posles dal:

netcat -w 30 -l -p 8023 ${REMOTE} | zfs receive -uvFd backup

Ale nepochopil jsem proc je to cele slepene tou pipou dohromady.

Btw. kdysi jsem cetl o nejakem problemu netcatu pri ukoncovani dat..

[JanM]

Ta pipa mezi netcaty je tam "zbytečně" z pohledu posílání dat - neb přes ní žádná netečou (tedy doufám).

Jenže kdyby tam nebyla, tak by to nemohl být "one-liner", ne?

Alespoň předpokládám, že použitím roury dojde k současnému spuštění příkazu před i za rourou; jinak bych musel spustit nejprve naslouchací netcat (na pozadí), a teprve poté ten posílací na $REMOTE.

Mezitím jsem hledal na Síti všech sítí a také jsem narazil na informace o problémech s ukončováním. Jenže analýza tcp dumpu je pro mne vyšší dívčí, takže asi zatím ponechám Intel Atom potit přes SSH.

[NN]

Tak v tom pripade bych tam spise dal ;, nebo && .. netcat klidne muze pockat. Analyza tcpdumu by byla dobra, jeho vystup staci poslat do souboru (-w) a potom otevrit pres ethereal jako .pcap ..