Questions about storage, hard-links and spin-up/down

[SirCadian]

I'm running Unraid 7.12.6.  I've been a happy user of unraid for a few years now.  I'm thinking about re-organising my data and had a couple of questions:

1. If I create a user share and map it to a number of disks, do those disks only spin-up individually rather than as a group when a file is accessed?  i.e. I have usershare1 allocated to disk1 & disk2, and I have the Dynamix Cache Directories plugin installed and set to cache usershare1.  If I read a file through usershare1 that is physically on disk 2, will only disk 2 spin up?

 

2. Do hard-links work for user shares?  i.e. Can a hard-link be created on disk1 in usershare1 that links to a file on disk2 in the same user share? I understand that I don't get to decide which disks these reside on...just trying to understand if hard-links will only work intermittently in a user share context (depending on whether unraid decides to locate the hard link and file on the same disk).

 

Thanks in advance for any help.

 

-----------------------------------

Update

I found a good explainer on hard-links and how they work here -https://www.redhat.com/sysadmin/linking-linux-explained

I used that to run a quick experiment in the terminal to look at hard-links and if/how they work in an Unraid user share context.  Hard links do seem to work in user shares.  If you attempt to create a hard link to a file in a user share, a hard link will be created to the file on the same physical disk as the file, even if your allocation method would ordinarily put any new files on a different disk.

e.g. I have a "Backups" share set to high-water allocation between disk1 and disk3.  disk1 is 89% full, disk3 is 17% full.  All new files in the share are normally allocated to disk3.  I created a file directly on disk1 (by creating it in /mnt/disk1/Backups) and then created a hard link to that file through the user share (by creating it in /mnt/user/Backups).  The hard link winds up sitting in disk1, not disk3.  As hard links take very little space (they report to be the same size as the file they link to but in practice are just the size of the filename plus a few bytes that point to the actual file) this would make sense...they're not going to fill up the disk.

-------------------------------------

Update 2

Ran some tests to work out spin up/down behaviour.  I span down disk2 & disk3 and did a recursive directory listing of disk2 in a terminal (ls -alR /mnt/disk2).  Neither disk spun up so I'm guessing that Dynamix Cache Directories is doing its job.  I then accessed a file that is physically located on disk2 via a user share that is allocated to both disk2 and disk3. Only disk2 spun up, disk3 stayed in standby.

 

Hopefully this will be of use further down the line to someone else who has similar questions.

Edited January 25 by SirCadian