Sure, but one of the most common causes of disks being filled on Linux is either the kernel or some process running as root filling the disk with endless repeating log entries.
It's a good point that the process that is flooding the disk could be running as root and therefore bypasses the reserved blocks restriction.
It's also worth noting that the kernel is not a process and it does not write directly to files in the conventional sense. syslog-ng or its equivalents (which do run as root) will pick up messages from the kernel's circular ring buffer at /dev/kmsg and write them to a text file such as /var/log/kern.log, so it's possible that the kernel or one of its modules are verbose enough that syslog-ng causes that text file to get big. However, these log files can be limited to a certain size and/or logrotated[0] daily which will also remove log files older than a configured amount of time. In other words, there are better ways to manage servers than creating 8GB files as a bandaid.
Log files are awful, log rotation is even worse. Logs are a continuous, persistent stream of messages that sometimes gets expunged when too old. Log files try to flatten and serialize them, but the coordination and management of them is a hassle. An FS like Reiser where each log entry is a file arranged in directory trees by minute, hour, day, month, and year, or a sqlite database would make more sense than spewing blindly into a giant text file and praying that it works when another process comes along and moves things around underneath a running program.
This is why on *nix systems, each directory of the vfs that is intended to accumulate files OR have different mount options is broken-off into its own volume. / /home /usr /usr/local /var /var/log /var/lib/docker /var/lib/postgresql and so on.
