3

I am seeing a random behavior when copying from one server to another using rsync to the /dev/null of the destination server. This is as part my network performance testing, and I want to avoid Disk I/O in my testings. I have the same script in all my servers, but for some of them the destination /dev/null gets overwritten and becomes a regular file, and that breaks other things.

For the same server scp does not overwrite the destination /dev/null.

Before:

[root@localhost ~]# ls -l /dev/null
crw-rw-rw-. 1 root root 1, 3 Sep 11 09:24 /dev/null

Here is my rsync command:

rsync -v -e ssh --progress 500MB root@destination-server:/dev/null

After:

[root@localhost ~]# ls -l /dev/null
-rw-r--r--. 1 root root 104857600 Sep 11 10:09 /dev/null

Doing scp to the same server, does not break /dev/null

scp 500MB root@destination-server:/dev/null

Any idea why causes the random behavior? My servers are a mix of CentOS6 and 7

Thank You, Eilbron

Gordon Davisson
  • 11,216
  • 4
  • 28
  • 33
Eilbron
  • 31
  • 1
  • 2
  • if you aren't already doing so using a tool like iperf will give a better understanding of network performance than rsync over ssh – Mark Wagner Sep 11 '19 at 20:20

5 Answers5

3

rsync doesn't just copy files' contents, it also syncs file attributes. This is somewhat limited by the options you pass (or don't pass) to rsync, but only somewhat. rsync has a --devices option that makes it syncing device files as device files, but apparently not passing that option doesn't prevent it from syncing plain files as plain files.

More generally: /dev/null is a safe place to write data into; it is not safe to use it as a target for things that mess with file attributes or structure.

Gordon Davisson
  • 11,216
  • 4
  • 28
  • 33
1

I recommend using pv and ssh instead.

As others have noted, rsync will write to a temp file, then overwrite the original destination file with the temp file, which doesn't give you the effect you're looking for.

If you want to get your effective network speed, you could do this:

pv -r /dev/zero | ssh user@server "cat > /dev/null"

pv is a great tool for rate/flow analysis.

-r instructs pv to show the rate, so in the example above, pv is reading from /dev/zero and piping that into ssh and will display the rate at which data flows form /dev/zero through ssh.

If you want to test if your network can sustain a certain bandwidth, without saturating your network (which the above example will do), you can use -L to limit the rate, like this:

pv -rL 1K /dev/zero | ssh user@server "cat > /dev/null"

Other pv flags I typically use:

-p - show a progress meter. This works great when reading from a file, the progress meter will show you how much of the file has been read

-e - show eta

-t - display a timer

-N <name> - show a name for this output. This one is really useful when you pipe several pv commands together, they will "stack" their output in the display, just name each one differently to tell which statistics go with which step in your piped processes.

-s <size> - use this size when calculating progress and eta. Use this one when you're writing output to a file, and you already roughly know the size of the resulting file.

Dev Null
  • 121
  • 5
1

By default, rsync will

  • create a new file, and overwrite the original file with the new one
  • not treat any file as special (device, link, fifo etc).

Here is how syncing a file called passwd from directory a to directory b goes down:

Reads the source file

a/ OPEN passwd
a/ ACCESS passwd
a/ CLOSE_NOWRITE,CLOSE passwd

Creates temp file and moves data:

b/ CREATE .passwd.cBzlfu
b/ OPEN .passwd.cBzlfu
b/ ATTRIB .passwd.cBzlfu
b/ MODIFY .passwd.cBzlfu
b/ CLOSE_WRITE,CLOSE .passwd.cBzlfu
b/ ATTRIB .passwd.cBzlfu

Finalizes filename

b/ MOVED_FROM .passwd.cBzlfu
b/ MOVED_TO passwd

The last operation is what overwrites your /dev/null, because it simply overwrites the device file. You expect that it will write (append) into it, but it doesn't.

Switches --inplace and --partial are influencing the synchronization behavior.

The switch --devices also helpful

This option causes rsync to transfer character and block device files to the remote system to recreate these devices. This option has no effect if the receiving rsync is not run as the super-user (see also the --super and --fake-super options).

Perhaps you should also consider not syncing a file onto a device :) rsync can sync a file with a file, a device with a device, but you appear to sync a file onto a device. That will probably don't go.

asdmin
  • 2,050
  • 17
  • 28
0

For rsync not to overwrite devices, you can use the --write-devices flag:

   --write-devices          write to devices as files (implies --inplace)

example:

rsync -v -e ssh --progress --write-devices 500MB root@destination-server:/dev/null

Please note that by using ssh, you are also measuring the ability to encrypt traffic and not only the network performance. For pure network performance I recommend using either rsync own protocol or a different tool such as netcat.

As for the random behavior, there could be multiple reasons, most likely sometimes you use user root and sometimes you don't. I recommend avoiding using user root as much as possible.

niry
  • 155
  • 7
0

/dev/null is a character special file and, as you have discovered, copying to it using rsync as root will overwrite it. AFAIK, rsync will not do what you want it to do. It might be possible to pipe through ssh to cat.

time tar cf - file | ssh server "cat > /dev/null"
scarville
  • 51
  • 6