Situation is:

6 disks, no parity enabled (to speed things up a bit)

disk1 and disk2 excluded from usershare (lets call it Bshare). mnt/user0/Bshare

disk3 to disk6 part of Bshare (implicitly by not setting something else in include disks)

Permissions were set to secure.

Allocation method: fill-up

 

 

I did the rsync from the source server (also unraid)

rsync -avHXP --sockopts=SO_SNDBUF=524288,SO_RCVBUF=524288 . rsync://target/mnt/user0/Bshare

 

Now it happens, when disk3 is full the sync stops.

 

I changed the settings for Bshare:

explicitly include disk3 to disk6 for Bshare.

excluded disks: none (obviously this implies that disk1 and disk2 are not included, because the copying continued on disk4)

Allocation method: high-water

 

Started the process again, and it continued in the list.

 

(I simultaneusly changed permissions to public but I think thats not the problem.)

 

Is this a desired behaviour?

Shouldn't it work either way?

 

Edit:

Changed the allocation method back to "fill-up" and the running process stopped again.

Looks like it's the allocation method!?

What are your split levels and min free space settings?

You need to make sure that the Min Free space value is set to a least the size of the largest file you intend to copy or you will encounter this problem.

 

Split level can also come into play in such problems, but this case sounds like the Min Free Space value.

 

In my personal opinion the default for Min Free Space should not be zero, but instead something like 1% of he disk size as for most people that would be a reasonable default and would help avoid this sort of issue.

OK, min free space was still @default value 0KB.

 

But,

why is writing to disk3 possible with that setting and writing to the other disks not?

And why is writing possible with high-water and not with fill-up?

 

The disks are all empty.

Split level is set to automatic (default).

OK, min free space was still @default value 0KB.

 

But,

why is writing to disk3 possible with that setting and writing to the other disks not?

And why is writing possible with high-water and not with fill-up?

 

The disks are all empty.

Split level is set to automatic (default).

There is probably a LITTLE space available.  With a Min Free Space value of 0 that means that unRAID can create the initial 0 byte file, but then gets a failure when it tries to write data to the file.  When this happens unRAID simply reports a failure - it does not switch to another disk with plenty of free space.  UnRAID does not take into account the final file size when creating a new file on the array, just whether there is at least Min Free Space bytes available.  A non-zero value for Min Free Space stops unRAID from creating new files on a disk when the free space goes below that value.

Most FSs become horribly inefficient and, sometimes, unreliable, when a device has little free space left.  I might suggest that it would not be unreasonable to set the minimum free space to 5%, or more, of the total disk capacity.

Thanks to both of you!

I have been wondering why to set the value as you suggested.

The description in the help section of that setting points into another direction but

your explanation is quite reasonable.

One has to think around the corner in this case.

 

In fact, copying of a big file started while there was not enough space on the disk left.

Then it would stop with a transmission error.

In fact, copying of a big file started while there was not enough space on the disk left.

Then it would stop with a transmission error.

That would make sense.  As was mentioned there is no check made to see if a file will fit before copying of it starts - just that there is enough space to create the original 0 byte file that is later expanded during the copying process.    That is why the recommended value for Min Free Space is at least enough o hold the largest file you expect to copy as hat way you will not run out of space as it is being copied.

 

One point to note is that if you copy a file directly to a disk level share then no check is made that the file will fit as you are in control in such a case. 

The initial intention of "min free space" is to leave this amount of space unused, isn't it?

That means, this free space has to be filled "by hand".

The initial intention of "min free space" is to leave this amount of space unused, isn't it?

That means, this free space has to be filled "by hand".

Not quite - it is to stop you creating a NEW file on a User Share when it drops below this value.  It does not stop the value falling below this value if it happens after creating the file, but while the file is being copied.

 

As en example if you had that value set to 5GB and it was just over that value when you wanted to copy a 4GB file.  unRAID would let you start that copy as there was more than the Min Free Space available, but after the copy completed successfully there would only be 1GB free.  Conversely if you had it set to 4GB and the file to be copied was 5GB you can be in the case where the file copy starts because there is more than 4GB available, but then subsequently fails as there is not the 5GB free for the copy to succeed. 

 

That is why the recommendation is that the value should be as large (or larger) than the biggest file to be copied on the basis that files are copied in serial order.  If you are going to be copying multiple files at the same time, then the value needs to be increased to be larger than the worst combination of files you might be simultaneously copying.

As en example if you had that value set to 5GB and it was just over that value when you wanted to copy a 4GB file.  unRAID would let you start that copy as there was more than the Min Free Space available, but after the copy completed successfully there would only be 1GB free.

Understood.

 

But if I copied a .2GB file I would result in ~4.8GB free space.

Now unRAID would not write any other data to that disk, leaving it unused.

As en example if you had that value set to 5GB and it was just over that value when you wanted to copy a 4GB file.  unRAID would let you start that copy as there was more than the Min Free Space available, but after the copy completed successfully there would only be 1GB free.

Understood.

 

But if I copied a .2GB file I would result in ~4.8GB free space.

Now unRAID would not write any other data to that disk, leaving it unused.

Yes.

 

If you want to write to that space you could do it by copying to the disk share for that disk rather than using the user share.  Disk shares have no concept of Min Free Space.