Jump to content

Download to user or disk share?


Spies

Recommended Posts

I have set up a 5 drive array with 1 parity, no cache drive at the moment.

 

I intend to use sonarr and deluge to automatically download on to the unraid server, would I be better to use a disk share for the actual downloading then extract it to the user share once it is done?

 

Thanks.

Link to comment

I have set up a 5 drive array with 1 parity, no cache drive at the moment.

 

I intend to use sonarr and deluge to automatically download on to the unraid server, would I be better to use a disk share for the actual downloading then extract it to the user share once it is done?

 

Thanks.

 

You have to be careful. There is a known issue about copying from disk shares to user shares (User Share Copy Bug). Basically, if you copy a file from a disk share that is part of a user share, unRAID gets confused and doesn't realize that the source and target files are, in essence, the same file. And when the write starts the file is gone and the copy is unable to continue. Basically you lose any file where this happens.

 

But your concept is sound. Download to one disk and extract to another. It is a best practice to download to the cache drive (often an SSD) and then have it propagated to user shares. But in your case, with no SSD cache yet, the best you might do is have two different user shares, download to one and copy to the other. Using the share settings you can control which disk(s) are included in each share, and work it out so that the download goes to a specific disk that is not included in the user share for the actual media.

 

Good luck and welcome.

Link to comment

Both are technically possible.. But I would advice never using disk shares.. User shares are far more easier to work with and you do not run into issues when a disk becomes full (also: copying from disk share to user share can make you lose data..)... There is nog a real need to use a disk share, IF you absolutely want everything to go to one specific disk I would still advise using a user share and limiting that usershare to one disk...  That way if that disk becomes full you only need to make a change to the definition of the user share (allowing another drive) and you do not need to change the configuration of the dockers/vms/apps you are using..

 

Some users (including myself) also use a cache drive specific share for the downloads and then make sure completed files go to the array..

 

In my case transmission, deluge and sabnzbd download to a cache drive share, then couchpotato and sickrage look at the cache-drive and move completed downloads to the array.. Makes sure that unpack actions are nog hampered by the parity speed..

Link to comment

Both are technically possible.. But I would advice never using disk shares.. User shares are far more easier to work with and you do not run into issues when a disk becomes full (also: copying from disk share to user share can make you lose data..)... There is nog a real need to use a disk share, IF you absolutely want everything to go to one specific disk I would still advise using a user share and limiting that usershare to one disk...  That way if that disk becomes full you only need to make a change to the definition of the user share (allowing another drive) and you do not need to change the configuration of the dockers/vms/apps you are using..

 

Some users (including myself) also use a cache drive specific share for the downloads and then make sure completed files go to the array..

 

In my case transmission, deluge and sabnzbd download to a cache drive share, then couchpotato and sickrage look at the cache-drive and move completed downloads to the array.. Makes sure that unpack actions are nog hampered by the parity speed..

This is exactly how I do things and what I also advise. Proper use of user share settings gives you all the control you need.
Link to comment

I guess another benefit is that you can spin down the entire array, just use the cache drive during the day and then the mover process can move the data at night?

Depends on your specific use. I have many user shares that are cache-no, and so are written directly to the array. And I have some that are cache-only, and are never moved.

 

For example, you could have a download share of some kind that was cache-only, and some other application that moved those files from that cache-only share to a cache-no share.

Link to comment

I guess another benefit is that you can spin down the entire array, just use the cache drive during the day and then the mover process can move the data at night?

Depends on your specific use. I have many user shares that are cache-no, and so are written directly to the array. And I have some that are cache-only, and are never moved.

 

For example, you could have a download share of some kind that was cache-only, and some other application that moved those files from that cache-only share to a cache-no share.

 

Me too. I have "cache only" shares and "non-cache" shares. I do not use the feature that moves data at 2am.

 

In the early days, drives were slower and unRaid's parity writing was not as efficient. Write speeds in the 8-10 mb/sec range were common, vs ~60 mb/sec copying to an unprotected disk. At that time, I was using my own version of a cache disk that I called staging to copy data from my workstation to my array. Then I'd queue some copies to run overnight from that disk mounted outside the array to the array. I suggested this feature and it was added to unRAID. Using the cache as a layover for data made a huge difference from the perspective of me sitting at my workstation - something like 6x as fast! The write penalty happened overnight when I was sleeping.

 

In today's world, unRAID's parity writes are often in the 40 mb/sec range, or even higher. The speed copying directly to an SSD cache might be closer to 80 mb/sec, gated by the network. That's 2x as fast but not 6x. But once the file arrives on the array disks, the file is under the protection of unRAID's parity mechanism. Many of us are more than willing to let it take 2x as long to get it immediately protected.

 

(If you have a cache pool maybe you are protected from data loss while on the cache. But many people, me included, don't see a need to protect the cache data and only have a single cache disk. I prefer to have my data on the protected array as quickly as possible.)

Link to comment

I upload all my non critical data to a cache drive which has a couple of shares on it and then use a script to move the files to a specific disk in the shame share a few times a month. I also have my cache setup to not to use the mover simply because I don't need it to and have been using Disk Shares since day one for moving files and User Shares for my devices to access and play the files.

 

Honestly the only real reason I use my Cache disk is to allow my disks to sleep and have instant on for the data that was recently uploaded. After two weeks or so the data is moved into the array and in my mind old data, but protected data for future use.

 

I'm kind of a Control freak so I put things where I want them and can't imagine changing that anytime soon. Lol

Link to comment

I upload all my non critical data to a cache drive which has a couple of shares on it and then use a script to move the files to a specific disk in the shame share a few times a month. I also have my cache setup to not to use the mover simply because I don't need it to and have been using Disk Shares since day one for moving files and User Shares for my devices to access and play the files.

 

Honestly the only real reason I use my Cache disk is to allow my disks to sleep and have instant on for the data that was recently uploaded. After two weeks or so the data is moved into the array and in my mind old data, but protected data for future use.

 

I'm kind of a Control freak so I put things where I want them and can't imagine changing that anytime soon. Lol

 

The issue is that you CAN be a controllfreak without making your own life difficult... Create a usershare called "UDisk1" and authorise only disk to write to it. This gives you the same benefit as when writing to a disk share without running the risk of corrupting data, or having to change individual docker configurations when a disk is near-full.

 

Ofcourse the nice thing in unraid is that you can do things in a multitude of ways, but for new years I try to advise to not use disk-shares, since there is no real need to but there -is- a risk..

Link to comment

I upload all my non critical data to a cache drive which has a couple of shares on it and then use a script to move the files to a specific disk in the shame share a few times a month. I also have my cache setup to not to use the mover simply because I don't need it to and have been using Disk Shares since day one for moving files and User Shares for my devices to access and play the files.

 

Honestly the only real reason I use my Cache disk is to allow my disks to sleep and have instant on for the data that was recently uploaded. After two weeks or so the data is moved into the array and in my mind old data, but protected data for future use.

 

I'm kind of a Control freak so I put things where I want them and can't imagine changing that anytime soon. Lol

 

The issue is that you CAN be a controllfreak without making your own life difficult... Create a usershare called "UDisk1" and authorise only disk to write to it. This gives you the same benefit as when writing to a disk share without running the risk of corrupting data, or having to change individual docker configurations when a disk is near-full.

 

Ofcourse the nice thing in unraid is that you can do things in a multitude of ways, but for new years I try to advise to not use disk-shares, since there is no real need to but there -is- a risk..

 

Very true.

I just make it a practice to only copy or move files from from disk share to disk share period and allow people to read from User Shares. Its how I keep my sanity some. lol

I never thought of making up a share and just changing the settings now and then as I need to. Interesting concept. Thanks for the idea, I actually might have a use for that idea.

 

I think the reason I never played with User Shares was I didn't want to tinker with figuring out Slip levels. Just blew my mind trying to wrap my brain around it some. ;)

Link to comment

I understand split levels, but my preferred way of keeping things together is just to limit a user share to a single disk until it gets too full. Then I just allow it to use another disk, which it will use for any more writing due to allocation and min free. Repeat as needed. So far only my Movies share spans 2 disks. Each of my other user shares fit within a single disk, often sharing the disk with other user shares.

 

And I have backups and dual parity, so I'm not concerned with losing a whole share due to all of its "eggs in one basket". Never really understood that reasoning anyway. If you have some things you don't mind losing, spreading out the things you don't want to lose doesn't really help anything. You just need a better backup plan.

Link to comment

2.5" really needs an SSD to make it worth wasting a SATA port on. Since you said you don't have cache, I would use it as cache. There is some question about whether SSDs should be used in the parity array anyway. And unless you know why you should manage the drive yourself separately, it is simpler to let unRAID manage it for you as cache. Each user share has settings for how and whether it uses cache which gives you all the flexibility you need.

Link to comment

2.5" really needs an SSD to make it worth wasting a SATA port on. Since you said you don't have cache, I would use it as cache. There is some question about whether SSDs should be used in the parity array anyway. And unless you know why you should manage the drive yourself separately, it is simpler to let unRAID manage it for you as cache. Each user share has settings for how and whether it uses cache which gives you all the flexibility you need.

Good call.

Link to comment

Archived

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

×
×
  • Create New...