Tengo algunos problemas con NFS, y me gustaría intentar usar simplemente el viejo TCP.

Sin embargo, no tengo idea de por dónde empezar.

En cuanto al hardware, estoy usando un cable cruzado ethernet para conectar en red dos netbooks.

Para conectarlos en red, escribo

$ sudo ifconfig eth0 192.168.1.1 up && ping -c 10 -s 10 192.168.1.2 && sudo /etc/init.d/nfs-kernel-server start

en el primer netbook y

$ sudo ifconfig eth0 192.168.1.2 up
$ ping -c 10 -s 10 192.168.1.1
$ mount /mnt/network1

en el segundo

donde /mnt/network1se especifica en / etc / fstab como

192.168.1.1:/home /mnt/network1 nfs noauto,user,exec,soft,nfsvers=2 0 0

así como en /etc/exports(usando la sintaxis de ese archivo), en el primer netbook.

Lo anterior funciona bien, pero los archivos y directorios son enormes. Los archivos promedian aproximadamente medio gigabyte por pieza, y los directorios tienen entre 15 y 50 gigabytes.

Estoy usando rsyncpara transferirlos, y el comando (on 192.168.1.2) es

$ rsync -avxS /mnt/network1 ~/somedir

No estoy seguro de si hay una manera de ajustar mi configuración de NFS para manejar mejor los archivos grandes, pero me gustaría ver si ejecutar un rsyncdemonio sobre TCP antiguo funciona mejor que rsyncsobre NFS.

Entonces, para reiterar, ¿cómo configuro una red similar con TCP?

ACTUALIZAR:

Entonces, después de un buen intento a las pocas horas de sacarme del pantano de mi propia ignorancia (o, como me gusta pensar, levantarme con mis propias botas), se me ocurrieron algunos datos útiles.

Pero antes que nada, lo que me llevó en este camino de conejos en lugar de simplemente aceptar la mejor respuesta actual fue: nces un programa increíblemente genial que resueltamente no funciona para mí. He probado el netcat-openbsdy netcat-traditionalpaquetes sin ningún tipo de suerte.

El error que obtengo en la máquina receptora ( 192.168.1.2) es:

me@netbook:~$ nc -q 1 -l -p 32934 | tar xv
Can't grab 0.0.0.0:32934 with bind
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

route da:

me@netbook:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         dir-615         0.0.0.0         UG    0      0        0 wlan0
link-local      *               255.255.0.0     U     1000   0        0 eth0
192.168.0.0     *               255.255.255.0   U     2      0        0 wlan0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

Pero, aquí están las buenas noticias: tener las direcciones IP estáticas establecidas /etc/network/interfaces, lo que comencé a hacer mientras intentaba nctrabajar, solucionó todos mis problemas de NFS y reavivó mi amor por NFS.

La configuración exacta que utilicé (con 192.168.1.1la primera netbook, por supuesto) fue:

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0

Con esa configuración, las dos netbooks podrán hacer ping entre sí directamente después de arrancar, sin siquiera una ifup.

De todos modos, todavía me gustaría ver ncen acción, así que espero que alguien me ayude a depurar este proceso.

El camino rapido

La más rápida manera de transferir archivos a través de una LAN probable es que no es rsync, a menos que haya pocos cambios. rsync pasa bastante tiempo haciendo sumas de verificación, calculando diferencias, etc. Si sabe que va a transferir la mayoría de los datos de todos modos, simplemente haga algo como esto (nota: hay múltiples implementaciones de netcat; revise el manual para las opciones correctas. En particular, la suya podría no querer -p):

user@dest:/target$ nc -q 1 -l -p 1234 | tar xv

user@source:/source$ tar cv . | nc -q 1 dest-ip 1234

Que usa netcat (nc ) para enviar tar a través de una conexión TCP sin procesar en el puerto 1234. No hay cifrado, comprobación de autenticidad, etc., por lo que es muy rápido. Si su conexión cruzada se ejecuta a gigabit o menos, vinculará la red; si es más, vinculará el disco (a menos que tenga una matriz de almacenamiento o un disco rápido). Las vbanderas para tar hacen que imprima los nombres de los archivos a medida que avanza (modo detallado). Con archivos grandes, prácticamente no hay gastos generales. Si estuvieras haciendo toneladas de archivos pequeños, lo apagarías. Además, puede insertar algo como pven la tubería para obtener un indicador de progreso:

user@dest:/target$ nc -q 1 -l -p 1234 | pv -pterb -s 100G | tar xv

Por supuesto, también puede insertar otras cosas, como gzip -1 (y agregar el zindicador en el extremo receptor; el zindicador en el extremo emisor usaría un nivel de compresión superior a 1, a menos que establezca la variable de entorno GZIP, por supuesto). Aunque gzip probablemente será más lento, a menos que sus datos realmente se compriman.

Si realmente necesitas rsync

Si realmente solo está transfiriendo una pequeña porción de los datos que han cambiado, rsync puede ser más rápido. También es posible que desee ver el-W--whole-file opción / , como con una red realmente rápida (como una conexión cruzada) que puede ser más rápida.

La forma más fácil de ejecutar rsync es a través de ssh. Querrá experimentar con los cifrados ssh para ver cuál es el más rápido, ya sea AES, ChaCha20 o Blowfish (aunque existen algunas preocupaciones de seguridad con el tamaño de bloque de 64 bits de Blowfish), dependiendo de si su chip tiene el AES de Intel -NI instrucciones (y tu OpenSSL las usa). En un ssh lo suficientemente nuevo, rsync-over-ssh se ve así:

user@source:~$ rsync -e 'ssh -c [email protected]' -avP /source/ user@dest-ip:/target

Para ssh / sshd anteriores, intente aes128-ctroaes128-cbc en lugar de [email protected].

ChaCha20 sería [email protected] (también necesita un ssh / sshd lo suficientemente nuevo) y Blowfish sería blowfish-cbc. OpenSSH no permite ejecutar sin un cifrado. Por supuesto, puede usar las opciones de rsync que desee en lugar de -avP. Y, por supuesto, puede ir en la otra dirección y ejecutar el rsync desde la máquina de destino (pull) en lugar de la máquina de origen (push).

Hacer rsync más rápido

Si ejecuta un demonio rsync, puede deshacerse de la sobrecarga de cifrado. Primero, crearía un archivo de configuración de daemon ( /etc/rsyncd.conf), por ejemplo en la máquina fuente (lea la página de manual de rsyncd.conf para más detalles):

[big-archive]
    path = /source
    read only = yes
    uid = someuser
    gid = somegroup

Luego, en la máquina de destino, ejecutaría:

user@dest:~$ rsync -avP source-ip::big-archive/ /target

También puede hacer esto al revés (pero, por supuesto, tendrá que configurar la lectura solo como no). Hay opciones de autenticación, etc., consulte la página de manual para obtener más detalles.

¿Cómo? O TL; DR

El método más rápido que he encontrado es una combinación de tar, mbufferyssh .

P.ej:

tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"

Con esto, he logrado transferencias de red local sostenidas de más de 950 Mb / s en enlaces de 1 Gb. Reemplace las rutas en cada comando tar para que sean apropiadas para lo que está transfiriendo.

¿Por qué? mbuffer!

El mayor cuello de botella en la transferencia de archivos grandes a través de una red es, con mucho, la E / S de disco. La respuesta a eso es mbuffero buffer. Son en gran medida similares pero mbuffertiene algunas ventajas. El tamaño predeterminado del búfer es de 2 MB para mbuffery 1 MB para buffer. Es más probable que los buffers más grandes nunca estén vacíos. Elegir un tamaño de bloque que sea el múltiplo común más bajo del tamaño de bloque nativo tanto en el sistema de archivos de destino como en el de destino dará el mejor rendimiento.

Buffering es lo que hace que todo la diferencia! ¡Úselo si lo tiene! Si no lo tienes, ¡consíguelo! Usar (m}?buffermás cualquier cosa es mejor que cualquier cosa por sí mismo. Es casi literalmente una panacea para las transferencias lentas de archivos de red.

Si está transfiriendo múltiples archivos, úselos tarpara agruparlos en un solo flujo de datos. Si es un archivo único que puede usar cato redireccionamiento de E / S. La sobrecarga de tarvs. cates estadísticamente insignificante, por lo que siempre uso tar(o zfs -senddonde puedo) a menos que ya sea un tarball . Ninguno de estos está garantizado para darle metadatos (y en particular catno lo hará). Si desea metadatos, lo dejaré como un ejercicio para usted.

Finalmente, el uso sshde un mecanismo de transporte es seguro y lleva muy poca carga. Nuevamente, la sobrecarga de sshvs. nces estadísticamente insignificante.

Ni siquiera necesita usar TCP. AoE es una implementación de ATA a través de Ethernet, siendo la capa 2, es un enfoque de gastos generales más bajos sin conocimiento de la pila TCP / IP. Le proporcionará la transferencia más rápida posible con la menor sobrecarga. ***

https://en.wikipedia.org/wiki/ATA_over_Ethernet

*** si la red es el cuello de botella, asegúrese de enviar datos comprimidos.