Does "allowed storage of the target path within the data structures used for storing file information on disk (inodes)" mean that a fast symlink stores the path of the linked file inside the inode of the fast symlink
Yes
Does a fast symlink, as a file itself, actually only have an inode and has no file content?
Depends what you mean by "has file content". No symlinks have file content in the sense that you cannot open() them and read() from them. But in the meaning implied by the text you quoted, "The file contained the textual reference to the link’s target". So, yes, that textual reference can be considered the file's "content".
This content is the same regardless of whether the symlink is a fast symlink or a slow symlink. How and where the filesystem choses to store that information in its on-disk data structures is an implementation detail and does not affect this.
Does a slow symlink, as a file itself, have an inode and some file content which is the target path?
From that same point of view, yes!
What does "if the target path exceeds the available inode space" mean?
Depends on the filesystem and the kind of data structures it used to store inodes and how much spare space is in those data structures and whether they are variable-sized or fixed size. The maximum length of the target path of a symlink before it has to fall back to being stored as a slow symlink is an filesystem implementation detail.
By the way, nothing prevents a particular filesystem from using the same trick to store the contents of a short regular file to save space and disk access.
Is there any command that can check if a symlink is a fast or slow one?
At best, filesystem debugging or dumping tools. And it will be completely dependent on the type of filesystem you are interested in (xfs, ext*, btrfs, etc...)
When a symlink has file content, what is the command to show the content of the symlink? (So that if a fast symlink doesn't have file content and a slow one has, we can verfiy that.)
You can obtain the target path (contents) of a symlink with readlink, but ls -l will work too.
There’s no way to tell ln to create “fast” or “slow” symlinks, the file system determines how it stores symlinks.
Dealing with symlink representation on optical media is up to the program handling the conversion, or the file system driver providing access to the medium, not up to the source file system. For example, mkisofs can use Rock Ridge extensions or TRANS.TBL files to represent symlinks. It can also handle hard links.
Best Answer
If you tar up the symlink, then you can copy the tarball over to the remote machine any way you like. When you untar it, you'll find that you've only copied the symbolic link and nothing else. For example:
To test this, first I created a text file.
Then create a symlink to the file and compress it into a tar gzip.
Transfer this file to your other machine and then uncompress it:
You will find that the symlink is there, but not the original file that it had pointed to.
Of course, if you wanted to transfer both the original file and the symlink while preserving their relationship, you can put them both in the tarball and they would both be transferred, and the symlink should still be correctly pointed to the original file when you uncompress the tarball in the destination location.