[Documentation] A few minor improvements (#21998)

doc/040_backup.rst

@@ -497,6 +497,8 @@ By specifying the option ``--one-file-system`` you can instruct restic
 to only backup files from the file systems the initially specified files
 or directories reside on. In other words, it will prevent restic from crossing
 filesystem boundaries and subvolumes when performing a backup.
+Internally, restic identifies a file's filesystem by the "device ID"
+that is returned by calling lstat() on the file.
 
 For example, if you backup ``/`` with this option and you have external
 media mounted under ``/media/usb`` then restic will not back up ``/media/usb``
@@ -660,6 +662,12 @@ If there is a **bind-mount** below a directory that is to be saved, restic desce
 archived as a block device file and restored as such. This also means that the content of the
 corresponding disk is not read, at least not from the device file.
 
+**Socket files** are not backed up because they represent active connections by running processes
+and are only meaningful if created by those processes.
+
+**FIFO files** are backed up, but because their contents are volatile and never stored on disk,
+only the file system entry and metadata will be backed up.
+
 By default, restic does not save the access time (atime) for any files or other
 items, since it is not possible to reliably disable updating the access time by
 restic itself. This means that for each new backup a lot of metadata is

doc/050_restore.rst

@@ -92,9 +92,12 @@ By default, restic does not restore files as sparse. Use ``restore --sparse`` to
 enable the creation of sparse files if supported by the filesystem. Then restic
 will restore long runs of zero bytes as holes in the corresponding files.
 Reading from a hole returns the original zero bytes, but it does not consume
-disk space. Note that the exact location of the holes can differ from those in
-the original file, as their location is determined while restoring and is not
-stored explicitly.
+disk space. Note that restic does not keep track of which files were originally
+sparse or at what locations sparse holes were. When restoring, restic will create
+a sparse hole (by seeking forward instead of writing data) for any range of zeros
+at the start of a blob. This range can span the entire blob. Because large files
+result in blobs much larger than file system blocks, restoring a large sparse file
+with many holes may make it significantly larger than the original sparse file.
 
 Restoring extended file attributes
 ----------------------------------