Jump to content

Docker directory


deaerator

Recommended Posts

Can someone tell me if there is a difference in using these directories when using a docker file

 

/mnt/cache/appdata

 

or

 

/mnt/user/appdata

 

i see in some configuration files people use either or both, I know they point to the same location but is there a difference between the two.

Link to comment

I would recommend settings the fodler to be cache only but accessing it using only the FUSE layer folder "/mnt/user/...".

 

The reason being that if you stick to the FUSE layer any action that start and end is on the same physical disk unRAID will be instant.

 

If you mix and match you will often find unRAID will revert to the slow duplicate and then delete safe actions. Net result is the same but slower and a bunch of needless disk thrashing

Link to comment

I would recommend settings the fodler to be cache only but accessing it using only the FUSE layer folder "/mnt/user/...".

 

The reason being that if you stick to the FUSE layer any action that start and end is on the same physical disk unRAID will be instant.

 

If you mix and match you will often find unRAID will revert to the slow duplicate and then delete safe actions. Net result is the same but slower and a bunch of needless disk thrashing

 

This is new to me.

 

/mnt/user/cache would give better performance than /mnt/cache ?

 

So I would create a user share called cache and only include my chance drive ?  Can it be shared as something other than cache, eg /mnt/user/apps ? I don't use my cache drive for caching.  Just for apps and now docker

Link to comment

I would recommend settings the fodler to be cache only but accessing it using only the FUSE layer folder "/mnt/user/...".

 

The reason being that if you stick to the FUSE layer any action that start and end is on the same physical disk unRAID will be instant.

 

If you mix and match you will often find unRAID will revert to the slow duplicate and then delete safe actions. Net result is the same but slower and a bunch of needless disk thrashing

 

This is new to me.

 

/mnt/user/cache would give better performance than /mnt/cache ?

 

So I would create a user share called cache and only include my chance drive ?  Can it be shared as something other than cache, eg /mnt/user/apps ? I don't use my cache drive for caching.  Just for apps and now docker

/mnt/user/cache is not the same thing as /mnt/cache. /mnt/cache is the cache drive. /mnt/user/cache is a user share named cache. If you had a cache-only user share named cache it would be /mnt/cache/cache. I think you would be better off not doing this since it might confuse things.

 

A cache-only share named apps can be accessed as either /mnt/cache/apps or /mnt/user/apps.

 

Any user share is a root folder on one or more drives. Conversely, any folder at the root of cache or any array disk is automatically a user share. And, of course, setting a share to cache-only will keep mover from moving it.

Link to comment

I would recommend settings the fodler to be cache only but accessing it using only the FUSE layer folder "/mnt/user/...".

 

The reason being that if you stick to the FUSE layer any action that start and end is on the same physical disk unRAID will be instant.

 

If you mix and match you will often find unRAID will revert to the slow duplicate and then delete safe actions. Net result is the same but slower and a bunch of needless disk thrashing

 

This is new to me.

 

/mnt/user/cache would give better performance than /mnt/cache ?

 

So I would create a user share called cache and only include my chance drive ?  Can it be shared as something other than cache, eg /mnt/user/apps ? I don't use my cache drive for caching.  Just for apps and now docker

 

Hypothetical example :

 

Lets say you have a file called "file" and you place it in "/mnt/cache/incoming" and then you move this file to "/mnt/cache/complete". Since the source and destination are the same physical drive the move operation is just a rename and is instant.

 

Now lets do the same file move using "/mnt/cache/incoming" and then you move this file to "/mnt/complete". Lets also assume that these folders are both on the same physical drive in this case the cache drive (e.g. in unRAID land complete is set to be allowed to use the cache drive feature ensuring this). Because one is a FUSE share and the other is a direct disk share unRAID can and often does get confused and the move will not be instant. What will actually happen is the file will be copied, once that has worked it will delete the original.

 

You can see how this is a bunch of needless disk thrashing. Now most people dont notice it since most file actions are still fast especially with SSD but it still is way slower than instant and very noticeable if you have big files.

 

Try it yourself and see :)

 

Morla of the story, consider using the FUSE shares as much as possible.

Link to comment

Ok.  So while it's hypothetically better, in my use case in makes no difference, I think.

 

/mnt/cache/download and /mnt/cache/complete are on the same cache drive.

 

Then there is a cron job that copies the contents of /mnt/cache/complete to /mnt/user/videos/incoming which is obviously on the array.

Link to comment

...

Then there is a cron job that copies the contents of /mnt/cache/complete to /mnt/user/videos/incoming which is obviously on the array.

 

Is /mnt/user/videos/incoming set to be allowed to use the cache drive?

 

No, the cache drive is not used as a cache.

Link to comment

It will still be cache only :)

 

All that using the FUSE share does in this case is ensure that operations that ideally should be instant as source and destination are on the cache drive are in fact instant.

 

Ideally a user should not have to care about this an uNRAID would handle it magically under the hood but currently it doesn't so if you are setting up docker volumes that could be caught out by this issues it makes sense to take it into account

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...