This one was bugging me for a while, and I think just finally figure it out...

 

Anytime I download something large to my server from the internet, I always make sure to pre-allocate all space so I don't have to worry about any other concurrent downloads growing beyond the capacity of whatever disk (or disks) they're writing to, but I kept running out of space on certain disks, even though I made sure there was enough space to download whatever it was before I started. I rearranged some files, evened the disks out, and finish the download. This kept happening, so I rearranged everything again, played with max free space, tried changing the unRAID allocation method to "Most free" thinking that would solve it. It did not. I finally started poking around the files directly, thinking there may have been some error, but looking at them, they were all there, taking up the whole size of whatever the final downloaded size would be (Verified at unRAID OS level with "ls -lah" command at terminal). Everything looked in order, until I started looking at the properties of individual files (Using Windows File Explorer, unsure of Linux terminal command to output that). I noticed that one file is a few GB large, the "Size on disk" was only a few hundred MB. Basically what looks to be happening, is the download app (Most commonly uTorrent) is creating the files at the size they're intended to be, but since it doesn't have the complete data, it uses junk data and overwrites it with real data as it downloads. My guess is unRAID ignores this junk data, and only processes whatever real data is there for advertised free space. So if I have a 100GB file I'm downloading, and uTorrent's junk data is only a few hundred MB, unRAID's allocation method will try saving the file onto any share with a few hundred MB to spare, causing drives to run out of space when it starts to overwrite with real data

 

Now we're here. Currently, my workaround is to load up the Web GUI and see which drive has the needed amount of space, and to save that file directly to the diskXX share, rather than to a user share, so I can keep track of what data is going to which drive. Obviously not an ideal solution, hopefully there's another way

Phew, that's one helluva report!  Thank you for sharing all the detail.  We'll have to look at this with Tom when he returns.

 

If anyone else is reading this thread and has had this issue, please reply as well and let us know.

I can't speak to this specifically, but I know before I went with a vm and was running utorrent on my PC, I saved to the PC and then copied to the array (cache) when completed. It made a world of difference in speed, stability, etc.

 

This would probably be a bandaid solution or maybe not. Worth a look on both sides.

 

This one was bugging me for a while, and I think just finally figure it out...

 

Anytime I download something large to my server from the internet, I always make sure to pre-allocate all space so I don't have to worry about any other concurrent downloads growing beyond the capacity of whatever disk (or disks) they're writing to, but I kept running out of space on certain disks, even though I made sure there was enough space to download whatever it was before I started. I rearranged some files, evened the disks out, and finish the download. This kept happening, so I rearranged everything again, played with max free space, tried changing the unRAID allocation method to "Most free" thinking that would solve it. It did not. I finally started poking around the files directly, thinking there may have been some error, but looking at them, they were all there, taking up the whole size of whatever the final downloaded size would be (Verified at unRAID OS level with "ls -lah" command at terminal). Everything looked in order, until I started looking at the properties of individual files (Using Windows File Explorer, unsure of Linux terminal command to output that). I noticed that one file is a few GB large, the "Size on disk" was only a few hundred MB. Basically what looks to be happening, is the download app (Most commonly uTorrent) is creating the files at the size they're intended to be, but since it doesn't have the complete data, it uses junk data and overwrites it with real data as it downloads. My guess is unRAID ignores this junk data, and only processes whatever real data is there for advertised free space. So if I have a 100GB file I'm downloading, and uTorrent's junk data is only a few hundred MB, unRAID's allocation method will try saving the file onto any share with a few hundred MB to spare, causing drives to run out of space when it starts to overwrite with real data

 

Now we're here. Currently, my workaround is to load up the Web GUI and see which drive has the needed amount of space, and to save that file directly to the diskXX share, rather than to a user share, so I can keep track of what data is going to which drive. Obviously not an ideal solution, hopefully there's another way

From your description it sounds as if the problem might be that you are specifying a user share and unRAID is saving a file to a disk that does not have enough free space to hold the whole file?  At the time a file is created unRAID does not know how big a file is going to be so picks the disk assuming a zero size according to the allocation level, split level and min-free-space settings.  If the file being written grows to exceed the free space on the selected drive then you get an out-of-space error reported for that file.  unRAID will not take any action for a given file after its initial creation at the point the file grows to use all available free space on a disk to switch to a different one 

 

This is why the min-free-space setting should be at least as large as the largest  file you intend to write to a user share.  If you are going to be writing multiple files in parallel to a user-share then the min-free-space value  needs to be the sum of these file sizes to stop an inappropriated disk from being selected to hold the file.

 

Specifying a disk share directly by-passes this issue as you have uniquely specified the target and the unRAID auto-selection criteria for selecting a destination disk do not come into play.

 

could this be the explanation of the behaviour you are encountering?

 

I guess there could also be an interaction with the downloading software if it initially creates a file larger than the final size, and then truncated it to the target size on completion?

Phew, that's one helluva report!  Thank you for sharing all the detail.

 

But of course. Never too many details when it comes to bug reports!

 

From your description it sounds as if the problem might be that you are specifying a user share and unRAID is saving a file to a disk that does not have enough free space to hold the whole file?

 

I think you're confusing the problem with part of my troubleshooting. My problem, or rather my assumption about the problem, is essentially how unRAID is perceiving certain data. Here's a visual:

 

 

The "Size on disk" will gradually grow as more of the real data comes in, but the advertised size stays the same. Using disk shares is how I'm getting around the problem. Because I know how big the file is eventually going to be, I can pick the best drive for it manually

Now here is the same file, with some more "real" data downloaded

 

 

As you can see, the size on disk has increased, but the other size has not

 

Though, funnily enough, it didn't stop downloading because it ran out of space. It seems to have been because of the issue in my other thread 

What filesystem are you running on your drives?

 

I remember seeing talk about changing settings for one of the docker container image in how it preallocates space for  the docker.IMG and how it differs depending on the filesystem used and how it reports the space used by the image. The post might have even been by Tom and used tech methods like fallocate or the like. There was mention of benefits in the image though being set to 10 Gigs wouldn't use the full 10 but only how much was actually used if it was on BTRFS and possibly XFS but in order to do so, there had to be different code paths on creation of the image/file.

 

That right there got me to thinking how filesystem types and how the client preallocates the space could play a big difference and be exactly what you're seeing here.

 

 

What filesystem are you running on your drives?

Good point!  I am not sure which of the file system types allowed supports 'sparse' files (which is what this looks like) where the app can specify a max file size and delay space being allocated until the relevant parts of the file are actually written.  I would be surprised if it is anything unRAID specific but more likely generic Linux capability.

What filesystem are you running on your drives?

 

Still running ReiserFS on all the drives

This error occurs with or without virtualization. I'm currently running unRAID natively for troubleshooting some other issues, and still hitting this wall. I ended up needing to buy a new 4TB drive just so I can copy the half completed files over to it, so I can then resume them. Hopefully this gets taken care of soon, because I'm out of drive bays now

Has anyone taken a look at this? My 4TB drive I purchased above is now running low on space, so this is becoming a problem again

So I'm assuming this is when you're downloading to the array from a Windows device like a PC or laptop, not when using a plugin or container to do so, correct?

So I'm assuming this is when you're downloading to the array from a Windows device like a PC or laptop, not when using a plugin or container to do so, correct?

 

Correct. All data is manipulated outside of unRAID. I don't have any plugins or containers

So I'm assuming this is when you're downloading to the array from a Windows device like a PC or laptop, not when using a plugin or container to do so, correct?

 

Correct. All data is manipulated outside of unRAID. I don't have any plugins or containers

OK, looking into this.

Hi, EGOvoruhk.

 

I've never had an issue like this, after several years of using unRAID.  However, I've always used a cache drive, and I don't use uTorrent.

 

Since others use Torrent clients quite a bit, there must be relatively straightforward methods to get them to play nice in an unRAID environment. 

 

I suspect the most straightforward solution would be to try adding a cache drive.  Besides the speed improvements, a cache drive should allow uTorrent to build the incoming file on a single drive until it's completely downloaded, then transfer that file to an array drive with adequate space to store it.  You'll also avoid having to manually pick which array drive receives the file, which is one of the primary benefits of user shares.

 

Cache drives don't have to be blazingly-fast or particularly large.  I've used an old WD 640GB 7200RPM drive since day 1, with good results.

 

If you have any way to add a cache drive, please try that avenue and report back.

 

-- stewartwb

If you have any way to add a cache drive, please try that avenue and report back.

 

I actually used to run a cache drive, but pulled it because of this other bug that I submitted

EGO,

 

Wanted to get back to you on this issue.  Check out this page:  http://www.mediacentermaster.com/wiki/index.php?title=How_to_Specify_Locations_to_the_uTorrent_Folder_Structure

 

Per this screenshot:

 

 

You can specify where to put new downloads vs completed downloads.  The simple fix to your problem would be to specify your local machine for the "put new downloads in" setting and then use the apps "move completed downloads to" setting to specify a user share on unRAID over the network.

 

Can you try this and let us know if this solves the issue?

My (main) local machine is a VM with very small storage on the main drive because I have a very large array to write to, so this "fix" sadly isn't much use

I'm not entirely sure I understand the issue.  Probably what's going on is that your downloading client is creating a sparse file or using fallocate() to pre-allocate space to the file.  Please see if this issue persist in -rc4 because in this release we added the fallocate() capability to user share file system.  If your client is indeed using fallocate() this I think this issue should be solved.

Right. uTorrent uses sparse files during download which are the cause of this issue.

 

If RC4 would not fix it, go in uTorrent - Preferences - Advanced - and untick  diskio.sparse_files option. 

 

Please note that this way, when a large download starts (e.g. a DVD ISO...) a lot of traffic is instantly generated to the array and client could lag until file generation ends. 

For anyone able to, please test on RC4 or later and report back if this is still an issue.  If not, we will mark this one solved.

For anyone able to, please test on RC4 or later and report back if this is still an issue.  If not, we will mark this one solved.

 

Still an issue on 6.0.1

For anyone able to, please test on RC4 or later and report back if this is still an issue.  If not, we will mark this one solved.

 

Still an issue on 6.0.1

Not sure I follow, did you make adjustments to the torrent downloaded as suggested. There was a suggestion from me and one from someone else.

Not sure I follow, did you make adjustments to the torrent downloaded as suggested. There was a suggestion from me and one from someone else.

 

No, I didn't make the client changes, as I thought the RC4 comment was because a sparse file fix was implemented. Was that not the case? I'd rather fix it at the source, and not have to configure every app/terminal that uses sparse files

Right. uTorrent uses sparse files during download which are the cause of this issue.

 

If RC4 would not fix it, go in uTorrent - Preferences - Advanced - and untick  diskio.sparse_files option. 

 

Please note that this way, when a large download starts (e.g. a DVD ISO...) a lot of traffic is instantly generated to the array and client could lag until file generation ends. 

See the above post which gave an alternate suggestion if rc4 didn't fix.