High-Water Disk usage?????

[ich777]

Hello, can somebody help me with this?

Should High-Water work like the picture below?

Or do i missunderstud something?

 

[John_M]

It could work like that. It depends entirely on how you have split levels set for each of your shares.

[itimpi]

That picture does not show enough information to draw any conclusions.

 

One thing you have to remember is that the ‘Split Level’ setting on shares over-rides Allocation method when selecting a disk for a new file so the path to files can be relevant if you have any restrictions imposed by Split Level.

[ich777]

Split levels are set to default 'Automatically split any directory as required'.

That's a fresh install of unraid and nothing was changed.

I'm on unraid 6.7.2

 

These are 4 x 6TB WD drives with cache disabled and no parity drive.

No other array devices on this server.

Edited October 26, 2019 by ich777

[itimpi]

Were all 4 drives always there?    Which drive are new files going to?    At this point from the screen shot I would expect them to be going to disk4.

[ich777]

Yes, all drives are always there a completely new setup.

When i've taken the screenshot it copied to disk1 then to disk 2 and now to disk4.

I think this is not like it should be...

Disk1 is 94% full and the server reminds me of every percent, i don't understand why it does this....

At some point everything is getting really weired how it copies files to the disks.

[John_M]

How about the Included disks and Excluded disks settings for each share? If a share has only, say, Disk1 included then new files will only be written to that disk.

[ich777]

Like i've said above i changed nothing.

Thats the stock settings without anything changed.

No exclusions or inclusions or anything.

Nothing changed.

 

Don't get me wrong i'm not new to unraid but it acts a little weired

Edited October 26, 2019 by ich777

[John_M]

Diagnostics would help to remove the guesswork.

[ich777]

9 hours ago, John_M said:

Diagnostics would help to remove the guesswork.

I attached the diagnostig logfiles.

 

Also now i get a no space left on device message...

Also the filesizes don't exceed the set limit.

 

Also after waking up and it now has finished copying over all files it looks like this:

chipsserver2-diagnostics-20191027-0653.zip

Edited October 27, 2019 by ich777

[itimpi]

29 minutes ago, ich777 said:

I attached the diagnostig logfiles.

 

Also now i get a no space left on device message...

Also the filesizes don't exceed the set limit.

 

Also after waking up and it now has finished copying over all files it looks like this:

chipsserver2-diagnostics-20191027-0653.zip 83.3 kB · 0 downloads

How are you copying the files?    If you are not doing over the network then you may be by-passing the user share system.

 

the diagnostics look like they were taken after a reboot - not while a copy was actually in progress - is this the case?

 

[ich777]

10 minutes ago, itimpi said:

How are you copying the files?    If you are not doing over the network then you may be by-passing the user share system.

What's the difference here? I copy it from the shell to /mnt/user/... to the apropriate share.

 

10 minutes ago, itimpi said:

the diagnostics look like they were taken after a reboot - not while a copy was actually in progress - is this the case?

Nope, no restart bevor downloading the diagnostics.

 

 

I now set it to Most-Free and it seems to work now.

Edited October 27, 2019 by ich777

[itimpi]

I have spotted one anomaly in your diagnostics that might explain your symptoms!   You have a share called 'Serien' which is set to a split level of 1  which means that any sub-folder on that share is constrained to the disk on which it is first created.   This will apply regardless of allocation method so is that the behaviour you want?

Edited October 27, 2019 by itimpi

[ich777]

10 minutes ago, itimpi said:

I have spotted one anomaly in your diagnostics that might explain your symptoms!   You have a share called 'Serien' which is set to a split level of 1  which means that any sub-folder on that share is constrained to the disk on which it is first created.   This will apply regardless of allocation method so is that the behaviour you want?

For that share yes but that share is not affacted...

I think i will further investigate and keep you updated if i solve the problem.

[itimpi]

2 minutes ago, ich777 said:

I think i will further investigate and keep you updated if i solve the problem.

OK.   This is the first time I have heard of high-water allocation not working as expected that has not been tracked down as either a misunderstanding of how it works or a configuration issue.

[Squid]

6 hours ago, ich777 said:

What's the difference here? I copy it from the shell to /mnt/user/... to the apropriate share.

 

Copying or moving / renaming?

 

If you are moving / renaming from one share to another share, then the underlying system will ignore any and all settings (split levels, allocation methods, includes / excludes), and leave the file(s) on the same disk as the source, and potentially giving you the results you're seeing.