Question about how the cache drive works


zylander

Recommended Posts

So lets say I have a 12 drive setup; 10 storage, 1 parity and 1 cache.  Lets also say that I am using user shares to create the directory "Movies" which gets shared to an HTPC.  The "Movies" directory contains DVD rips in the form of Video_TS stored across a number of drives.  Now lets say I rip a DVD on my desktop and then transfer it over to the "Movies" directory on the unRAID server.  The newly ripped movie is transferred onto the cache drive first.  Now, I want to watch this movie on my HTPC, however the cache drive isnt set to start copying the newly ripped movie onto the array for another few hours.

 

My question is, while a newly copied file is sitting in "limbo" on the cache drive, is it still accessible from the directory it will eventually be copied to?  In the situation above, even though the movie is still sitting on the cache drive, will the HTPC see the new movie in the "Movies" directory?

Link to comment

While the movie is being watched on your HTPC , if by chance the "mover" process is invoked, open files will NOT be moved.  Mover will not affect your watching of the movie... 

 

The file(s) will only be moved when they are not open for reading/writing.  They will move the next night, when they are no longer open.

 

Joe L.

 

Link to comment

While the movie is being watched on your HTPC , if by chance the "mover" process is invoked, open files will NOT be moved.  Mover will not affect your watching of the movie... 

 

The file(s) will only be moved when they are not open for reading/writing.   They will move the next night, when they are no longer open.

 

Joe L.

 

 

 

 

 

Ok, so the HTPC will be reading the movie off the cache drive, but I will not have to navigate to the cache drive, correct? It will be as if the file is In the user shares directory with all the other movies?

Link to comment

While the movie is being watched on your HTPC , if by chance the "mover" process is invoked, open files will NOT be moved.  Mover will not affect your watching of the movie... 

 

The file(s) will only be moved when they are not open for reading/writing.   They will move the next night, when they are no longer open.

 

Joe L.

 

Ok, so the HTPC will be reading the movie off the cache drive, but I will not have to navigate to the cache drive, correct? It will be as if the file is In the user shares directory with all the other movies?

Correct.  You will see it as if it is already in the folder with the other movies.  The cache drive should be completely transparent to you, other than allowing faster writes to the server.
Link to comment

I got a question related to how cache disk works and hopefully someone could have some explanation for me.

 

As we can see from following output from syslog, an hour after mover finished its work, all disks (13 disks including cache disk) were spun down.

The question is "why ALL disks have to be spun up?", those data i copy to cache disk through user share should only affect some data disks but all.

I thought mover should base on user share configuration and figure out which disk has to be brought.

 

---------------------------------------------------------------- syslog ----------------------------------------------------------------------------------------------------

Aug 4 03:46:17 Tower logger: mover finished

Aug 4 04:45:48 Tower emhttp: shcmd (34): /usr/sbin/hdparm -y /dev/sdg >/dev/null

Aug 4 04:45:48 Tower emhttp: shcmd (35): /usr/sbin/hdparm -y /dev/sda >/dev/null

Aug 4 04:46:48 Tower emhttp: shcmd (36): /usr/sbin/hdparm -y /dev/sdj >/dev/null

Aug 4 04:46:48 Tower emhttp: shcmd (37): /usr/sbin/hdparm -y /dev/sdh >/dev/null

Aug 4 04:46:48 Tower emhttp: shcmd (38): /usr/sbin/hdparm -y /dev/sdf >/dev/null

Aug 4 04:46:48 Tower emhttp: shcmd (39): /usr/sbin/hdparm -y /dev/sdk >/dev/null

Aug 4 04:46:48 Tower emhttp: shcmd (40): /usr/sbin/hdparm -y /dev/sdd >/dev/null

Aug 4 04:46:49 Tower emhttp: shcmd (41): /usr/sbin/hdparm -y /dev/sdi >/dev/null

Aug 4 04:46:49 Tower emhttp: shcmd (42): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Aug 4 04:46:49 Tower emhttp: shcmd (43): /usr/sbin/hdparm -y /dev/sdl >/dev/null

Aug 4 04:46:49 Tower emhttp: shcmd (44): /usr/sbin/hdparm -y /dev/hda >/dev/null

Aug 4 04:46:49 Tower emhttp: shcmd (45): /usr/sbin/hdparm -y /dev/hdb >/dev/null

Aug 4 04:46:49 Tower emhttp: shcmd (46): /usr/sbin/hdparm -y /dev/sdb >/dev/null

 

Link to comment

I got a question related to how cache disk works and hopefully someone could have some explanation for me.

 

As we can see from following output from syslog, an hour after mover finished its work, all disks (13 disks including cache disk) were spun down.

The question is "why ALL disks have to be spun up?", those data i copy to cache disk through user share should only affect some data disks but all.

I thought mover should base on user share configuration and figure out which disk has to be brought.

 

Had the same problem.  You need to add the cache_dirs command to your go file to eliminate unnecessary spin up. The info can be found here under Keep directory entries cached.

Link to comment

 

Had the same problem.  You need to add the cache_dirs command to your go file to eliminate unnecessary spin up. The info can be found here under Keep directory entries cached.

 

Well, question i have this cache_dirs script running on my system already and judging by those output from syslog, i think those disks were brought up by cache disk mover that is why they all spun down 1 hour later at same time.

Link to comment

 

Had the same problem.  You need to add the cache_dirs command to your go file to eliminate unnecessary spin up. The info can be found here under Keep directory entries cached.

 

Well, question i have this cache_dirs script running on my system already and judging by those output from syslog, i think those disks were brought up by cache disk mover that is why they all spun down 1 hour later at same time.

The older cache_dirs script did not scan the /mnt/cache disk.  Does yours?  (newest version I posted yesterday does, although tip to fix the older version has been in thr thread for quite a while.)

 

Even so, the amount of data being moved from one disk to another can easily use up all the memory in your buffer cache, displacing older scanned directories.  In any case, I'm guessing that the user-share logic needed to spin up the drives to determine which drive had space as it performed the file copies... Do you have any specific allocation rules defined for user-shares, or just the default? 

 

How much memory do you have installed?  What does the output of

free

look like on your server?

Link to comment

That is an interesting idea, about whether the free space of user-shared drives might be spinning the drives up.  Would something like a df call be useful, added to the cache_dirs script?  I don't use User Shares myself, so can't test it.

 

When other uninvolved drives spin up on me, it is because of a third agent in the mix, a periodically polling program such as media software.  Here is my understanding of how this works:

* cache_dirs marks your selected files and folders as fresh, as frequently as it runs

* a demanding process (such as the mover script or any large copying job) then runs which floods the cache with fresh content

* this requires cache_dirs to run frequently, in order to make sure our selected folders are more fresh than the cached content of the copies or moves

* what actually spins other drives up though, is not the cache_dirs script, or the mover script or any large copies, but a third agent that is accessing our cached folders, on a periodic schedule

 

For me the third agent is SageTV, which is checking all of my media folders for new or changed content every 5 minutes.  So long as the directory entries for these media folders are in the cache, then it never needs to spin the drives up.  But if cache_dirs is not running frequently enough, to mark them fresher than the large copy or move is doing, then they may get dumped from the cache, and when SageTV wants to check the folder, the drive will have to spin up to reload its directory entries.  Or if I forgot to select a particular media folder for directory caching, then of course it will be dumped quickly, if something major is using up the caching.

 

In addition to Joe's idea, check whether you have a media center type program that is regularly polling the drives that unexpectedly spun up, drives that you think should not have spun up.  And check to see that cache_dirs is configured correctly for ALL of the folders that might be polled/checked.  Plus, make sure cache_dirs is running frequently enough.  You may have to tweak the -m and -M parameters, to force it to run more frequently.

Link to comment

The older cache_dirs script did not scan the /mnt/cache disk.  Does yours?  (newest version I posted yesterday does, although tip to fix the older version has been in thr thread for quite a while.)

 

Even so, the amount of data being moved from one disk to another can easily use up all the memory in your buffer cache, displacing older scanned directories.   In any case, I'm guessing that the user-share logic needed to spin up the drives to determine which drive had space as it performed the file copies... Do you have any specific allocation rules defined for user-shares, or just the default?   

 

How much memory do you have installed?   What does the output of

free

look like on your server?

 

 

I don't have access to my machine now, so can't tell how many free memory had left.

 

I have cache_dirs setup long time ago and i had my cache disk setup just days ago. i allocated dedicated disk for user shares for example, i have one disk for my BD movies, one for my music collection and another one for photo, other user shares that need larger space might across multiple disks. Those data i copied to cache disk through user shares last night are video data which are neither BD video nor music. So when i saw from syslog all disks, including disks for BD and music share, are spun up by mover i am surprised.

 

Before i setup cache disk, every time i copy data to user share, system will only spin up those affected disk and i never see all of them have to be spun up. that is why when mover has to spin up all them that is really surprise me. meanwhile i have 6GB of memory in my system.

 

 

Link to comment

In addition to Joe's idea, check whether you have a media center type program that is regularly polling the drives that unexpectedly spun up, drives that you think should not have spun up.  And check to see that cache_dirs is configured correctly for ALL of the folders that might be polled/checked.  Plus, make sure cache_dirs is running frequently enough.  You may have to tweak the -m and -M parameters, to force it to run more frequently.

 

I do have a HTPC with media center but that machine is in sleep mode at night and only wake up when it needs to record TV program or by myself. At time, mover is working i don't think this HTPC is up and running.

 

Link to comment

The older cache_dirs script did not scan the /mnt/cache disk.  Does yours?  (newest version I posted yesterday does, although tip to fix the older version has been in thr thread for quite a while.)

 

Even so, the amount of data being moved from one disk to another can easily use up all the memory in your buffer cache, displacing older scanned directories.   In any case, I'm guessing that the user-share logic needed to spin up the drives to determine which drive had space as it performed the file copies... Do you have any specific allocation rules defined for user-shares, or just the default?   

 

How much memory do you have installed?   What does the output of

free

look like on your server?

 

 

I don't have access to my machine now, so can't tell how many free memory had left.

 

I have cache_dirs setup long time ago and i had my cache disk setup just days ago. i allocated dedicated disk for user shares for example, i have one disk for my BD movies, one for my music collection and another one for photo, other user shares that need larger space might across multiple disks. Those data i copied to cache disk through user shares last night are video data which are neither BD video nor music. So when i saw from syslog all disks, including disks for BD and music share, are spun up by mover i am surprised.

 

Before i setup cache disk, every time i copy data to user share, system will only spin up those affected disk and i never see all of them have to be spun up. that is why when mover has to spin up all them that is really surprise me. meanwhile i have 6GB of memory in my system.

 

 

As I said, the only way for unRAID to know which disk is the best disk to copy to from the cache disk is for it to check the available free space on each data disk.  It probably had to spin them up to do that.   Cache_dirs just has data on files and directories, assuming it is in the buffer cache, not on free space, and older versions of cache_dirs did an incomplete job... it was improved as we learned more.   How old is your version?

 

Joe L.

Link to comment

As I said, the only way for unRAID to know which disk is the best disk to copy to from the cache disk is for it to check the available free space on each data disk.  It probably had to spin them up to do that.   Cache_dirs just has data on files and directories, assuming it is in the buffer cache, not on free space, and older versions of cache_dirs did an incomplete job... it was improved as we learned more.   How old is your version?

 

Joe L.

 

The cache_dirs i am using is version 1.5 according to change log. and the way i run it in go script is "cache_dirs -d 5 -m 3 -M 5 -a"-noleaf" -w".

 

Regardless, i am not sure how does cache_dir going to change the way unRaid behave as i mentioned without cache disk whenever i copy data to unRAID through user shares only those affected disk will be spun up. A good example is , as i mentioned, i have a BD share which used disk3 in my system and in cache disk there is NO single entry of data which belongs to this BD share, When mover kick in why it need to spin up disk3 given that there is NO data will go to BD share? Even if mover has to spin up disks for checking up fre space then it should only spin up those disks associated with affected user share.

 

Link to comment

As I said, the only way for unRAID to know which disk is the best disk to copy to from the cache disk is for it to check the available free space on each data disk.  It probably had to spin them up to do that.   Cache_dirs just has data on files and directories, assuming it is in the buffer cache, not on free space, and older versions of cache_dirs did an incomplete job... it was improved as we learned more.   How old is your version?

 

Joe L.

 

The cache_dirs i am using is version 1.5 according to change log. and the way i run it in go script is "cache_dirs -d 5 -m 3 -M 5 -a"-noleaf" -w".

 

Regardless, i am not sure how does cache_dir going to change the way unRaid behave as i mentioned without cache disk whenever i copy data to unRAID through user shares only those affected disk will be spun up. A good example is , as i mentioned, i have a BD share which used disk3 in my system and in cache disk there is NO single entry of data which belongs to this BD share, When mover kick in why it need to spin up disk3 given that there is NO data will go to BD share? Even if mover has to spin up disks for checking up fre space then it should only spin up those disks associated with affected user share.

 

 

 

I decide to give it a try by copy some data to cache disk for one of user share and manually start mover through unRaid web interface. everything works fine only those affected disks are spun up while mover moving data however at end of operation right before i saw from syslog that mover report finished all disks are spun up.

 

------------------------------ one hour later from syslog, all idle disks are spun down ---------------------------------------------------------------------------------------------

Aug 4 22:04:50 Tower logger: mover finished

Aug 4 22:08:57 Tower ntpd[1465]: synchronized to 132.163.4.103, stratum 1

Aug 4 23:04:58 Tower emhttp: shcmd (68): /usr/sbin/hdparm -y /dev/sda >/dev/null

Aug 4 23:04:58 Tower emhttp: shcmd (69): /usr/sbin/hdparm -y /dev/sdf >/dev/null

Aug 4 23:04:58 Tower emhttp: shcmd (70): /usr/sbin/hdparm -y /dev/sdk >/dev/null

Aug 4 23:04:58 Tower emhttp: shcmd (71): /usr/sbin/hdparm -y /dev/sdd >/dev/null

Aug 4 23:04:58 Tower emhttp: shcmd (72): /usr/sbin/hdparm -y /dev/sdi >/dev/null

Aug 4 23:04:58 Tower emhttp: shcmd (73): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Aug 4 23:04:58 Tower emhttp: shcmd (74): /usr/sbin/hdparm -y /dev/sdl >/dev/null

Aug 4 23:04:58 Tower emhttp: shcmd (75): /usr/sbin/hdparm -y /dev/hda >/dev/null

 

 

 

------------------------ Couple hours later, scheduled mover operation kicked in ----------------------

As we can see even though there is only one file to move, all disks still have to be spun up.

 

Aug 5 04:30:01 Tower logger: mover started

Aug 5 04:30:58 Tower logger: `./Video/2002/\347\276\216\344\272\272/ehthumbs_vista.db' -> `/mnt/user0/./Video/2002/\347\276\216\344\272\272/ehthumbs_vista.db'

Aug 5 04:30:58 Tower logger: removed `./Video/2002/\347\276\216\344\272\272/ehthumbs_vista.db'

Aug 5 04:32:28 Tower logger: mover finished

Aug 5 05:33:33 Tower emhttp: shcmd (32): /usr/sbin/hdparm -y /dev/sdj >/dev/null

Aug 5 05:33:33 Tower emhttp: shcmd (33): /usr/sbin/hdparm -y /dev/sdg >/dev/null

Aug 5 05:33:33 Tower emhttp: shcmd (34): /usr/sbin/hdparm -y /dev/sdh >/dev/null

Aug 5 05:33:33 Tower emhttp: shcmd (35): /usr/sbin/hdparm -y /dev/sda >/dev/null

Aug 5 05:33:33 Tower emhttp: shcmd (36): /usr/sbin/hdparm -y /dev/sdf >/dev/null

Aug 5 05:33:33 Tower emhttp: shcmd (37): /usr/sbin/hdparm -y /dev/sdk >/dev/null

Aug 5 05:33:33 Tower emhttp: shcmd (38): /usr/sbin/hdparm -y /dev/sdd >/dev/null

Aug 5 05:33:33 Tower emhttp: shcmd (39): /usr/sbin/hdparm -y /dev/sdi >/dev/null

Aug 5 05:33:33 Tower emhttp: shcmd (40): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Aug 5 05:33:33 Tower emhttp: shcmd (41): /usr/sbin/hdparm -y /dev/sdl >/dev/null

Aug 5 05:33:33 Tower emhttp: shcmd (42): /usr/sbin/hdparm -y /dev/hda >/dev/null

Aug 5 05:33:34 Tower emhttp: shcmd (43): /usr/sbin/hdparm -y /dev/hdb >/dev/null

Aug 5 05:33:34 Tower emhttp: shcmd (44): /usr/sbin/hdparm -y /dev/sdb >/dev/null

 

Link to comment
  • 7 months later...

While the movie is being watched on your HTPC , if by chance the "mover" process is invoked, open files will NOT be moved.  Mover will not affect your watching of the movie... 

 

The file(s) will only be moved when they are not open for reading/writing.   They will move the next night, when they are no longer open.

 

Joe L.

 

Joe, sorry to grab this old thread but what will happen if the active open file is a .VOB and the moves moves all other files. Then, when the player switches to the next .VOB in the same directory, it won't be there?! It would be good if the mover handles those directories at once, i.e. if *any* files within is open, skip all the files inside.

 

 

Link to comment

While the movie is being watched on your HTPC , if by chance the "mover" process is invoked, open files will NOT be moved.  Mover will not affect your watching of the movie... 

 

The file(s) will only be moved when they are not open for reading/writing.   They will move the next night, when they are no longer open.

 

Joe L.

 

Joe, sorry to grab this old thread but what will happen if the active open file is a .VOB and the moves moves all other files. Then, when the player switches to the next .VOB in the same directory, it won't be there?! It would be good if the mover handles those directories at once, i.e. if *any* files within is open, skip all the files inside.

 

 

Easy answer. 

 

To the media payer, all the .VOB files appear to be in the same "user-share" directory.  Those in the "cache" drive are presented in the user-shares view of things as if they are already in their eventual protected data drive locations.  Even after being moved from one to the other, from the media player's perspective, it did not move at all.

 

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.