option requests verbose descriptions of what tar is doing. So you should be able to capture that output into a sort of log file. That way, if anything goes wrong, it's usually fairly easy to see what happened.
I generally use:
> tar.log 2>&1
from a Bourne-like shell ( for example bash ). I'm using ellipses ... to represent whatever other options might be needed. That captures both the standard output which lists each file that is included in the tar file, as well as the standard error output which contains the error messages.
As to limitations, there are a variety of limitations, and in a sense they change depending on what options you choose. So it's a bit of a broad topic to address generally.
I'm not entirely clear from what perspective you are asking the questions about disk space. But I can say this, with some versions of tar, gzip is run dynamically to create the tar file. You can verify this for your version in at least three ways. One, the command:
run from the command prompt, while tar is running, should show you that the gzip command is also running, as a child process of the tar command.
Two, the command:
should be replaced with the actual name of your tar file, should produce output showing, not that it is a tar file, but instead, that it is a compressed file, and that command is also to be run while the tar command is still running.
At one point in the past, some forms of compression used with tar were almost no different than running the tar command, and then running the compression command separately, except that the tar command ran the compression command for you, if you supplied the correct option to tar. In fact, with some forms of compression, that may still be the case. But at least in the Linux distro I use, gzip works right along with tar.
Three: you can monitor the space available on /tmp with the command
df -k /tmp
while the tar command is still running. In my case I see no substantial use of space on /tmp even while I'm creating a huge tar file with gzip compression.