Hi Gang,

 

I was downloading a couple of torrent files and came back to find a disk full error. There is plenty of room on Disk2 but it did not fall over, I have split level set to 999 just to take that out of the equation. I think this is a torrent issue and not a unRaid issue but wanted to make sure.

 

Thanks for the info!

 

John

Any Ideas on this anyone?

No ideas here.  Based on what you have told us so far, it should not have reported a full disk.  Can you give us more detail, such as what your share settings look like, what the directory structure looks like that you are saving to, what app reported the full disk and what was the exact message, etc.  I'm just reaching here, but since we must be missing something, I'm trying to come up with sufficient questions to turn up a possible cause, that will give someone an idea of what could be wrong.

 

A full disk error can sometimes be a default error for any problem with writing to a disk, if there were lazy programmers involved.  At one time, a full disk was almost always the reason for a failure to write, especially because disks were so small, so programmers did and probably still do cheat, and call any write error a full disk error.  Now, there are more issues possible, especially network related.  So you may want to consider anything that could have interrupted the save.  Check the syslog for entries about that time.

RobJ,

 

Thanks for the reply,

The program that was in use was uTorrent it was downloading updates to a rather large, 63gig folder. this was a 3rd? level folder, Structure of

Folder 1

  Folder 2

      Folder 3 I am D/L to.

 

at the time the folder was created and the d/l started I found that split level was set to 0 in version 4.4 I changed the split level to various levels all the way to 999 thinking that if I restarted it it would then fall over to the second disk but no go. If I initated a COPY from my pc to the folder it worked as it should and put the data that did not fit on disk 1 on disk 2 which is why I think it is an issue with the download client but I am not sure.

 

Unfortunatly there was a few restarts of the server involved so I dont seen anything from around that time in the log. The disk full error was in utorrent though not unRaid so it probably would not show there anyway.

 

Thanks again.

 

John

There have been several reports of difficulty with very large files of perhaps 40 gigs or larger.  One that was recent discovered that replacing the network card on the desktop machine solved the problem, no idea why.  Others have had no issues with files that large, and there is no known issue with the Reiser file system or unRAID with handling them.  I personally have not tried a file over about 10GB.

This situation is slightly different in the fact that I am using a bittorrent client on the server itself but anyway…  I am currently downloading a 64ish GB torrent that is is doing just fine.

 

You might want to look into running BubbaRaid on your server.  It has really changed the way I have used my server.  I no longer run a torrent client on my computer and do most of my downloading on the server itself.

Well the gigabit nic is new, I guess I could switch back to the onboard for a test. I just have to think of how to replicate it.....gonna have to move some stuff off the full disk and start a new download to it I guess.

 

I will look into bubbaraid i took a quick peek and it looks interesting.

 

Thank you for the replies.

 

John

at the time the folder was created and the d/l started I found that split level was set to 0 in version 4.4 I changed the split level to various levels all the way to 999 thinking that if I restarted it it would then fall over to the second disk but no go.

Changing the value after the d/l started might just be the issue. 

 

We do not know when the split level is read by the user-share file-system.  I suspect it might only be read once when the server is first started.  It might not be re-read until you re-start your server. 

 

Even though you reset the split level, it might not be recognized until you stop and re-start the array.  (I'm just guessing, but I'll bet it does not keep looking at the config file every time it goes to create a new file... That would be very inefficient.  It might be that it reads the user-share config once when it first is started.)

 

Joe L.

That makes sense, I will have to try to set the conditions up again to see what happens.