[SOLVED] Weird share issue ever since I added a new drive

[danioj]

Hi All,

 

New Year New Issue! 

 

A few weeks back I added a new drive to my array. See here: http://lime-technology.com/forum/index.php?topic=36833.0

 

My Disk Setup is shown here: https://drive.google.com/file/d/0B-RnlzEU8DW9VURvUUVsSDBiUGM/view?usp=sharing

 

All seemed good until now. I was just looking at my shares as I was thinking of adding another and I noticed that the available space on a few of my shares was less than what it should be. See here: https://drive.google.com/file/d/0B-RnlzEU8DW9SHdXRnhqNEdlX1E/view?usp=sharing

 

As you can see, the available space on the media share seems to be incorrect. There is only 2.30TB left on the Array. I can see how it is calculating the number. It appears to be adding the available space on the Cache Drive to the available space for the share. I thought at first that this must be by design, but then I realised that the other shares (which are set up the same) have their available space calculated correctly.

 

Here are my share settings:

 

Global Share Settings: https://drive.google.com/file/d/0B-RnlzEU8DW9R0dkN21MZUsxZm8/view?usp=sharing

Media Share Settings: https://drive.google.com/file/d/0B-RnlzEU8DW9Y01Jc0JVVHlyR00/view?usp=sharing

Documents Share Settings: https://drive.google.com/file/d/0B-RnlzEU8DW9OFoxckFERWNTRGs/view?usp=sharing

 

The only other thing I thought was that because the share is effectively using the cache drive in that there are files on the cache drive that are awaiting the mover to be run in several hours time (which is not the case for the other shares) is this perhaps why this calculation is being made.

 

My small fear is that there is something wrong with the setup and I did something wrong when moving my 3TB cache drive into the array and replacing the cache with a new 2TB drive as detailed in the link on the first line.

 

Or is this a bug in either Unraid or Dynamix?

 

Any comments good or bad are welcome.

 

Thank you

 

Daniel

[danioj]

OK, after some experimenting I realise what is going on. It is as I say below, because the share is effectively using the cache drive that is why this calculation is being made.

 

I added a file to my documents share (effectively putting the additional file on the Cache Drive) and went back and had a look at the shares tab. Low and behold the yellow ball indicating that the Cache drive contains files for the share (as expected) and the available space for that share has increased by the amount that is currently available on the Cache drive (just like the media share). I also realised I could hit the "Compute" link and that too indicated that the Cache drive was being used in the calculation for available space.

 

I find this an interesting implementation if it is by design. If not I wonder again if this is a bug in either Unraid or Dynamix?

[gundamguy]

I find this an interesting implementation if it is by design. If not I wonder again if this is a bug in either Unraid or Dynamix?

 

You are correct in how this is currently working. I think this was by design, but there has been debate in the past about what it ought to be doing. I personally agree with you, Cache Space is transient space, and should not be shown as being free space for the share. That said it’s space you can write too.

I can’t remember the behavior exactly, but if your cache becomes full doesn’t it disable your ability to write additional data to that share, until that data in cache is moved onto the array?  If that’s the case then the shares free space is only the space available on the cache right? Conversely I know that if the share on the array is full, the data on the cache will not move.

 

IMO I think the best solution would be to break this down into a more meaningful set of information.

• Free Space on Array (How much parity protected space is available for the share of total)

• Free Space on Cache (How much Cache space is currently available for the share of total cache)

• Total Free Space

 

There might be a good reason why it’s not like this though.

 

[JonathanM]

IMO I think the best solution would be to break this down into a more meaningful set of information.

• Free Space on Array (How much parity protected space is available for the share of total)

• Free Space on Cache (How much Cache space is currently available for the share of total cache)

• Total Free Space

When a network client asks unraid "how much free space is available", which number should unraid tell it? Currently what you see in the display is what unraid tells other machines, and if the display had 3 different numbers, you would run into a situation where someone says "I tried to write to unraid and windows said there wasn't enough space, but unraid says it's still got a little space left".

 

The current situation is a compromise to a rather complex problem. Any ideas on a better method would probably be welcomed.

[danioj]

IMO I think the best solution would be to break this down into a more meaningful set of information.

• Free Space on Array (How much parity protected space is available for the share of total)

• Free Space on Cache (How much Cache space is currently available for the share of total cache)

• Total Free Space

When a network client asks unraid "how much free space is available", which number should unraid tell it? Currently what you see in the display is what unraid tells other machines, and if the display had 3 different numbers, you would run into a situation where someone says "I tried to write to unraid and windows said there wasn't enough space, but unraid says it's still got a little space left".

 

The current situation is a compromise to a rather complex problem. Any ideas on a better method would probably be welcomed.

 

Just to add my thoughts - I think the Unraid should publish only that available space that exists on the Protected Array irrespective of what is available on the Cache Drive. It appears to me that in this scenario you could have 2 GB left on the Array, but succeed in copying a 4TB file to Unraid as the Cache Drive has a 6TB capacity. Then when the Mover initiates at 3am it fails because there is not enough space to copy to the array thus leaving the data unprotected. If you're not infront or near your box for a period of time then essentially you have a period where your data is not protected and at risk of data loss as a result of a failure to the Cache Drive.

 

I know all who use the Cache Drive run that risk anyway (between times The Mover is executed) but I think I would rather be advised that I can't copy the file to Unraid as at that moment (without some user intervention) there is no chance of this copy to the array succeeding irrespective of whether there is room on the Cache Drive or not. Seems safer to me, unless I've missed something.

[jevans04]

This issue is on the Roadmap for future fix/change.

 

http://lime-technology.com/forum/index.php?topic=35690

 

[danioj]

This issue is on the Roadmap for future fix/change.

 

http://lime-technology.com/forum/index.php?topic=35690

 

 

The OP is actually not a bug.  That said, it may be that we should consider changing how we report free space similar to how stewartwb is mentioning.  I'm going to move this to the roadmap as this isn't really a defect.

 

Good enough for me. Not a bug but is going to be changed. @jevans04, Thanks.

[BobPhoenix]

I can’t remember the behavior exactly, but if your cache becomes full doesn’t it disable your ability to write additional data to that share, until that data in cache is moved onto the array?

When cache is full the data is then transferred directly to the array bypassing the cache drive - or so I've seen posted.  I don't use cache drives - as cache drives anyway.