big jump in free space after update (5.0.4)

[david81]

So....is there something we need to do to get an official bug report filed on this one?

[DaleWilliams]

Send a PM to Tom...with a link to this thread...and a quick message that there seems to be a bug in the free space calculation.

Even better is a link to this thread at the point where you chime in with your free space issue.

 

[limetech]

Send a PM to Tom...with a link to this thread...and a quick message that there seems to be a bug in the free space calculation.

Even better is a link to this thread at the point where you chime in with your free space issue.

 

Since a user share is not a fixed storage device, "free space" is always going to be a bit "fuzzy".  Here's how it's calculated now:

 

1. add up the free space on every data disk the share already exists on, plus ones it's allowed to expand into.

2. if the share currently exists on the cache drive, include the free space of the cache drive in the total.

 

Also, total "used" space is calculated like this:

 

1. add up the space used by the share on every data disk the share already exists on.

2. if the share currently exists on the cache drive, include the amount of space used by the share on the cache drive in the total

 

The fuzziness comes in how to handle the cache drive.  Clearly you want to include any space used on the cache drive by a share in the total "used" calculation.  I think there are three ways to deal with free space on the cache drive:

 

a) include free space of cache drive in every share that is enabled to use the cache drive

b) include free space of cache drive for a share only if the share exists on the cache drive (this is what we do now)

c) never include the free space of the cache drive (unless it's a cache-only share)

 

Which one is "correct" is going to depend on:

- how you use the cache drive

- whether you write the share via the disk shares

- how often you have the mover set up to run

- if any applications rely on 'statfs' call to get free space for some operation (file move for example)

 

What the code does now is something of a compromise.  What I think is maybe a more realistic calculation would be:

 

d) never include the free space of the cache drive (unless it's a cache-only share), and also subtract the amount of storage the share is currently using on the cache drive from the total "free" for the share (presuming the data will eventually be moved from cache to array).  But calculating this number requires using the 'du' operation, which can be lengthy and probably would result in a spin-up of the cache drive.  Also you could get into a situation where you can no longer transfer data to the share even though there might be plenty of space on the cache drive.  (Though the mover would probably fail.)

 

[david81]

d) never include the free space of the cache drive (unless it's a cache-only share), and also subtract the amount of storage the share is currently using on the cache drive from the total "free" for the share (presuming the data will eventually be moved from cache to array).  But calculating this number requires using the 'du' operation, which can be lengthy and probably would result in a spin-up of the cache drive.  Also you could get into a situation where you can no longer transfer data to the share even though there might be plenty of space on the cache drive.  (Though the mover would probably fail.)

 

That sounds perfectly reasonable to me. Even better if there were an option to override it in the case where your data drives filled up and you'd still like to transfer to the share while waiting on a new drive to arrive or clear.

[DaleWilliams]

Thanks for the explanation, Tom.

I bookmarked this page and fully expect to refer back.

[david81]

I know this is dredging up a very old topic, but a quick search of the forum didn't turn up anything promising.
 

Has there been any more thought to changing the free space calc or making it user configurable?