For example `/<path_to_data>/data`, or even `/data`.
!!! info
The paths you use on the inside matter. Because of how Docker’s volumes work, passing in two or three volumes such as the commonly suggested `/tv`, `/movies` and `/downloads` makes them look like two or three file systems, even if they aren’t. This means hard links won’t work and instead of an instant move, a slower and more I/O intensive copy + delete is used.
The paths you use on the inside matter. Because of how Docker’s volumes work, passing in two or three volumes such as the commonly suggested `/tv`, `/movies` and `/downloads` makes them look like two or three file systems, even if they aren’t. This means hard links won’t work and instead of an instant move, a slower and more I/O intensive copy + delete is used.
@ -5,8 +5,7 @@ This basic example is based on the use of docker images
More info [HERE](/Hardlinks/Hardlinks-and-Instant-Moves/){:target="_blank" rel="noopener noreferrer"}
!!! attention ""
The default path setup suggested by some docker developers that encourages people to use mounts like `/movies`, `/tv` and `/downloads` is very suboptimal because it makes them look like two or three file systems, even if they aren’t. It is the easiest way to get started. While easy to use, it has a major drawback. Mainly losing the ability to hardlink or instant move, resulting in a slower and more I/O intensive copy + delete is used.
--8<--"includes/hardlinks/bad-path-suggestion.md"
But you're able to change this, by not using the pre-defined/recommended paths like:
The default path setup suggested by some docker developers that encourages people to use mounts like `/movies`, `/tv` and `/downloads` is very suboptimal and it makes them look like two or three file systems, even if they aren’t (*Because of how Docker’s volumes work*). It is the easiest way to get started. While easy to use, it has a major drawback. Mainly losing the ability to hardlink or instant move, resulting in a slower and more I/O intensive copy + delete is used.