AC86U rsync - no space left on device (28)

[Torson]

I'm running rsync (installed from Entware) between an AC86U (local) and AX56U (remote) to move some files between the two routers - both at 384.17.

The command:

rsync -avh --inplace --exclude '*.swp' -e 'ssh -p XXXXX -i /jffs/dropbear/private_key' admin@d.d.n.s-ip:/[remote_source] /[local_destination]

works as expected for a while, then the following error comes up:

rsync: write failed on "/[local_destination]": No space left on device (28)
rsync error: error in file IO (code 11) at receiver.c(374) [receiver=3.1.3]
rsync: [generator] write error: Broken pipe (32)

Then:

admin@RT-AC86U:/tmp/home/root# df -h
Filesystem                Size      Used Available Use% Mounted on
ubi:rootfs_ubifs         77.2M     63.9M     13.3M  83% /
devtmpfs                214.9M         0    214.9M   0% /dev
tmpfs                   215.0M    216.0K    214.8M   0% /var
tmpfs                   215.0M    215.0M         0 100% /tmp/mnt
mtd:bootfs                4.4M      3.3M      1.1M  75% /bootfs
tmpfs                   215.0M    215.0M         0 100% /tmp/mnt
mtd:data                  8.0M    588.0K      7.4M   7% /data
tmpfs                   215.0M    215.0M         0 100% /tmp
/dev/mtdblock8           48.0M     21.1M     26.9M  44% /jffs
/dev/mtdblock8           48.0M     21.1M     26.9M  44% /www/Main_LogStatus_Content.asp
/dev/sda1                27.4G      2.3G     23.6G   9% /tmp/mnt/asus
tmpfs                   215.0M    215.0M         0 100% /www/index_style.css
tmpfs                   215.0M    215.0M         0 100% /www/require/modules/menuTree.js

How can I avoid the /tmp directory being filled-up? There is plenty of room on the USB drive where the files are being copied to, and --inplace doesn't seem to make any difference.
Any suggestions?

 

[dave14305]

You must be missing the mount point folder name under /tmp/mnt in your rsync command. Therefore, everything is dumping in /tmp/mnt in RAM. Like /tmp/mnt/asus.

 

[Torson]

Yes, indeed, I had a typo in the [local_destination] which actually created another mount point, hence the leak to /tmp/mnt in RAM.
Thank you!