RaspberryPi A transferência de arquivos samba é extremamente lenta

0

Então estou extremamente confuso porque minha transferência de arquivos do samba é tão lenta que é inutilizável. Parece ser rápido no começo e depois fica preso ou extremamente lento, de modo que precisa ser redefinido. Uma abordagem semelhante com um RaspberryPi funcionou para mim no passado.

Para a configuração, eu tenho pelo menos dois RaspberryPi, digamos rasp1 e rasp2 . Em seguida, rasp1 mounts drive1 e rasp2 mounts drive2 . As unidades são unidades USB formatadas via ntfs ou ext4, variando de 2 a 6 TB. Então, na realidade, o RaspberryPi possui uma ou mais unidades montadas em USB montadas via mount /<device>/<identifier> <target_directory> . Então o samba é configurado para expor as unidades à rede como:

[storage]
  path = <path_to_directory_containg_mountpoints>
  public = no
  browseable = yes
  writeable yes
  create mask = 0777
  directory mask = 0777
  valid user = <list of valid users>

e é iniciado por meio de sudo /etc/init.d/samba start . Eu tenho uma configuração semelhante para rasp2 para que tanto rasp1 quanto rasp2 possam expor os Drives USB à rede e os clientes possam montá-los. Todo o princípio pode ser comparado a um NAS caseiro de RaspberryPi e drives USB externos.

Agora para os clientes: O cliente simplesmente monta as unidades nas quais está interessado e, no nosso caso, drive1 e drive2 via sudo mount -t cifs //<RaspberryPi_IP>/storage/<mountpoint_for_drive1> <target_directory> -o user=<user_from_list_of_valid_users>,gid=<local_usergroup>,sid=<local_user> para cada uma delas respectivamente. Todos eles estão na rede local.

O principal problema com essa abordagem é que as taxas de transferência de arquivos de drive1 para drive2 através do ponto de montagem dos clientes são terríveis. Quando eu instanato um progresso de transferência de arquivos com mv -vi "drive1/file1" "drive2/" ou rsync -a --info=progress2 --remove-source-files "drive1/file1" "drive2/" , o progresso depende do tamanho do arquivo. Se o arquivo for pequeno e menor que 1.8M, o arquivo pode ser transferido com facilidade, como eu esperaria. Se o arquivo for maior, parece que nada acontece. iotop mostra o pico inicial de transferência de dados de smbd e eu acho que a montagem e depois fica em 0% e fica lá por um longo tempo antes que outro pico aconteça. Então, tecnicamente, o arquivo seria transferido mesmo que esses picos estivessem a alguns minutos de distância.

O que eu acho que poderia ser: Agora, um pouco mais especulativo da rede para pacotes pequenos não é o problema: Se eu fizer um ping de 64 bytes eu recebo um ping constante de 0.3ms do RaspberryPi para o cliente ou o cliente para o RaspberryPi. Quando tentei algumas coisas, pareceu-me uma reinicialização ( sudo reboot do RaspberryPi, em seguida, remontar e reiniciar o samba) corrigiria o problema para uma determinada quantidade de operações de E / S, dependendo da quantidade de operações de E / S simultâneas antes de uma delas barracas. Talvez isso também esteja relacionado a um erro Resource temporarily unavailable que recebi algumas vezes, que é outro problema que tenho com essa configuração. Às vezes os pontos de montagem demoram muito tempo apenas para listá-los (não especialmente via o comando mount ), mas quando eu entro no diretório que várias unidades montam. Eu pensei que aquelas unidades vão dormir (às vezes eu até acho que elas vão dormir se eu executar uma consulta sobre elas, como find . -type f [...] ) então eu desativei o modo de espera com sudo /usr/bin/sdparm --clear=STANDBY /<device>/<identifier> no entanto até agora isso não me trouxe o esperado resultado. Outro problema que pensei ser o culpado foi um erro no sistema de arquivos. Devido a eu ter matado várias instâncias de rsync e mv que eram muito lentas, eu posso terminar uma delas muito cedo. Então eu corro sudo fsck /<device>/<identifier> para ext4 e sudo ntfsfix para ntfs respectivamente. Uma das unidades teve um problema, mas os problemas (listar diretórios que montam unidades sendo lentas, a transferência de dados sendo lenta) ainda permanecem mesmo depois de deixar fsck repará-la. Por vezes, é mostrado que htop tem um núcleo do RaspberryPi para utilizar 100% durante alguns segundos, até que nem iotop nem htop mostrem qualquer resposta esperada.

RaspberryPI OS is: Linux raspberrypi 4.14.34-v7+ #1110 SMP <time> armv7l GNU/linux
Client can be windows or linux
Samba on RaspberryPi is: ( 'samba --version' ) Version 4.5.12-Debian

TL; DR:

  • RaspberryPi usando o samba para montar unidades é extremamente lento para mover arquivos de (leitura).

  • A exibição de pontos de montagem por meio de ls leva muito tempo e às vezes até termina com Resource temporarily unavailable .

  • (Talvez um problema separado) Aciona a suspensão enquanto as Operações de IO são executadas nelas

por What 21.06.2018 / 17:36

0 respostas