I created dev/null using

mknod dev/null c 2 2

Your knowledge is outdated. Things do not work this way any more, now that NAS4Free is based on the likes of FreeBSD 10 and 11. (Nor are those the device numbers for the null device anyway.) Read the mknod manual. You can still run mknod to create device nodes in an actual disc or RAM filesystem, but the nodes that you create will be pretty much entirely useless. As you can see, the kernel does not let you open devices with them.

This is why in jails — actual jails, the ones that come with the operating system, not simple chrooted environments that one can set up with sshd_config — one obtains the device files by mounting a devfs instance within the jail. It is also why jails have knobs to control whether devfs can be mounted and what devfs ruleset applies to it.

If you want a /dev/null in your changed root environment, you'll have to use mount_nullfs to make the actual /dev tree visible within the changed root. If you use a bona fide jail, just configure it to mount a devfs on /dev.

If you do use a bona fide jail, you of course set it up to run sshd inside the jail, listening on the jail's IP address and enabled as a service in the jail's /etc/rc.conf in the normal way.

Further reading

• mknod. FreeBSD 11.0 Manual.
• devfs. FreeBSD 11.0 Manual.
• devfs.rules. FreeBSD 11.0 Manual.
• Documentation:Howto:Jails. NAS4Free wiki.
• Matteo Riondato. "Jails". FreeBSD Handbook.
• Scott Robb (2015-03-04). FreeBSD Jails.

By definition /dev/null sinks anything written to it, so it doesn't matter if you write in append mode or not, it's all discarded. Since it doesn't store the data, there's nothing to append to, really.

So in the end, it's just shorter to write > /dev/null with one > sign.

As for the edited addition:

The open(2) manpage says lseek is called before each write to a file in append mode.

If you read closely, you'll see it says (emphasis mine):

the file offset is positioned at the end of the file, as if with lseek(2)

Meaning, it doesn't (need to) actually call the lseek system call, and the effect is not strictly the same either: calling lseek(fd, SEEK_END, 0); write(fd, buf, size); without O_APPEND isn't the same as a write in append mode, since with separate calls another process could write to the file in between the system calls, trashing the appended data. In append mode, this doesn't happen (except over NFS, which doesn't support real append mode).

The text in the standard doesn't mention lseek at that point, only that writes shall go the end of the file.

So, is truncating /dev/null actually unspecified?

Judging by the scripture you refer to, apparently it's implementation-defined. Meaning that any sane implementation will do the same as with pipes and TTY's, namely, nothing. An insane implementation might do something else, and perhaps truncation might mean something sensible in the case of some other device file.

And do the lseek calls have any impact on write performance?

Test it. It's the only way to know for sure on a given system. Or read the source to see where the append mode changes the behaviour, if anywhere.