• MINIMUM FREE SPACE changes to a (bogus(?)) percentage

    RobertP

    By RobertP

      • Closed

    Am I confused/mis-understanding something? Am I thinking of a different field?  Or is this a bug? (Actually, even if I’m confused, I feel there IS a bug here.)

     

    THE ISSUE:

    MINIMUM FREE SPACE for a share

    unRAID 6.12.3

    Drives in share formatted with xfs

     

    HISTORY

    I used a 3rd party backup program to back up my home PCs.  I have the backup program (Macrium Reflect) write the backup files to a share on my unRAID server. 

    YEARS AGO, I had the backup program write each backup as one big file.  This caused issues – if unRAID started to write to drive 1 of the share, and that drive only had 1TB free, and the backup file ended up being 1.5TB, the backup would fail due to running out of free disk space on that drive since the one big file could not straddle two physical drives (even if both drives are in one share).

    I WAS TOLD to do two things:
    1) Tell my backup software:  Write the backups out in “chunks” (CHUNK is my word for it, that’s not the technical term!).  I chose 250GB (yea, I played it overly conservative, bigger chunks would probably be easier to keep track of!).

    2) Tell unRAID:  Use the MINIMUM FREE SPACE field to tell unRAID to NOT write to a disk within a share if that disk has less than xxGB free – instead pick another disk in the share to write to.  This way, no matter what unRAID allocation method was used (high-water, most-free, fill-up) and no matter what the disk size, unRAID would not try to put what MIGHT be a huge file onto an almost full drive.  I think I did 500GB (or was it 1TB? Either way, I gave myself extra “elbow room” over-and-above the “chunk size” of 250GB)

     

    This worked great for years.

     

    THE PROBLEM DETAIL:

    I recently upgraded to unRAID 6.12.3.  Not sure if this issue started with this version or an earlier version.  Since the backups have been working OK, I have not looked at that share definition in a long time.

     

    I just now looked at the share definition that holds my backups.  The MINIMUM FREE SPACE field now has a percentage, not an absolute number.  I tried changing it back to a number:

    500GB.  I hit enter, and it changes that number to 500000000 (a.k.a. 500,000,000), just like it used to.  But then it changes it to a percentage!?!?  And the percentage does not make sense (to me).

     

    This share is made up of 4 physical drives:

    12TB (currently 1.3TB free)

    12TB (currently 2.6TB free)

    6TB (currently 2.81TB free)

    16TB (currently 15.2TB free)

    I put 500GB (or 500 GB) in the MINIMUM FREE SPACE field, and unRAID eventually turns it into 25.6%

    I don’t see ANY situation using ANY of those numbers above (max individual size, total size, free size) where 25.6% equals 500 GB!?!?

    If I put in 1000GB (also tried 1tb or 1TB or 1 tb or 1 TB), it expands the number to 1000000000, but then it changes it to 51.2%!?!?!?  So is that saying if the entire share is more than half full, a file will not be written?  Or if an individual drive is more than half full, a file won’t be written to that drive?  That makes no sense at all – 1TB does NOT equal 51.2%!?!? 

    Is this simply a formatting error of how that field is displayed?  How can I be sure what the actual value is?  Or is unRAID actually doing a bad calculation?
    FYI - In the attached diagnostics, the share that I'm working with is named:  UR-BU-i9
    BUT I tried some other shares and they are also showing a similar issue - MINIMUM FREE SPACE is being converted to a weird percentage.

    ur1-wopr-diagnostics-20230717-2002.zip

    Go to reports Stable Releases

    User Feedback

    Recommended Comments

    JorgeB

    What is the share name? Note that if a pool is part of the share it will also be included in the calculations, e.g., if there's a 500GB pool and you set the minimum space to 250GB it would show in the GUI as 50%, since that's the space relative to the smallest device that belongs to that share.

    Link to comment
    itimpi

    I must admit that I find the % setting as very confusing.   Not sure what advantage it gives over having an absolute value.

    Link to comment
    RobertP

    the share that I'm working with is named:  UR-BU-i9.  Just a regular old-fashioned share w 4 drives.  In the past, it used to keep the absolute number, not a percent.  

    Link to comment
    JorgeB
    10 minutes ago, RobertP said:

    Just a regular old-fashioned share w 4 drives.

     

    Share exists on cache: 

    # Share exists on cache, disk6, disk7, disk8, disk9

    So as explained above cache size will also be taken into account for the percentage value.

     

    And since that drive is 2TB this is correct:

    Quote

    I put 500GB (or 500 GB) in the MINIMUM FREE SPACE field, and unRAID eventually turns it into 25.6%

     

    Link to comment
    RobertP

    I ran MOVER, cache drive is now empty (except for appdata and system of course).  I tried changing the MINIMUM DISK SPACE again - it is still reverting to a percent.
    I also tried a share that does NOT use cache (2ndary storage = NONE in this version's terms).  I put in an absolute value, and it returns a percent.

    Link to comment
    JorgeB
    4 hours ago, RobertP said:

    it is still reverting to a percent.

    This is normal, but the percentage will be now based on your smaller array disk.

     

    4 hours ago, RobertP said:

    I put in an absolute value, and it returns a percent.

    Again, this is normal.

     

     

     

    Link to comment
    itimpi
    50 minutes ago, JorgeB said:

    This is normal, but the percentage will be now based on your smaller array disk.

     

    As I have been reading this thread, if you currently have files on a cache disk then the % displayed will be relative to that pool? 

     

    If mover then moves the files to the array so there are no files longer on the cache pool I assume the % displayed will now change to be relative to the smallest array drive that is part of the share?

     

    Assuming that is correct then I can see how users will get confused when this % value appears to change without them making any change.

    Link to comment
    RobertP

    This is disappointing (and confusing) to me. 

    1) I want to be sure no file writing happens if the drive that initially gets picked has less than 500GB (like it used to work before) - I don't want the "write/no-write" decision (a.k.a. pick another drive) to be dependent on the server's drive size, but on the actual file being written and actual size I've specified.

    2) After the MOVER had completed, I put MINIMUM FREE SPACE to 500GB, it gets changed to 25.6%.  Drives in this share are:

    12TB (3.38 free)
    12TB (2.6 free)

    6TB (2.81 free)

    16TB (12.2 free)

    How does 500GB become 25.6%?  I'm not following the math, based either on total size of the smallest drive or free size of the smallest drive or smallest free space on any drive.  25.6% of 6TB is 1.5TB, not .5TB (500GB).  25.6% of free space is 2.81*.256=.71TB (710GB).  25.6% of 2.6 (smallest free space) is .66TB (660GB), not 500GB. 

    3) If it is based on smallest FREE space on any given drive, this is really bad since free space will always be changing, which means I may not be able to be sure that the backup "chunk" does not start to write on a drive w/o enough space since the free space will always be changing.

    4) Since this share makes use of cache (a.k.a. "primary storage/secondary storage") even nothing is on cache at the moment, is the calculation based on the size of my cache drive (which is 2TB)?  Does that mean, if my total backup is more than the cache drive's 2TB (actually 1.5TB due to my MINIMUM FILE SIZE setting), that it will no longer write to cache initially, and then, once cache is full, write direct to the physical drive?  Instead, is my backup just going to abend due to lack of space on the cache???  OUCH if that's the case. 
    4a) Or will it still write to cache until it reaches 1.5TB used and then still switch to writing the next "chunks" of the backup process directly to the share?
    5) In addition, the HELP does not offer any explanation of this - it still only talks about an absolute value.  If this change is to remain in place (I hope you consider putting it back to the old way), then the help needs to explain the math and WHY it changes to a percent.  And if this MINIMUM SPACE now also is based on the cache drive size and the smallest of ALL drives involved (in my case the 4 share drives and the cache drive), this needs to be clearly stated in the help (by "help" - I'm referring to when I push F1 to get explanation of the fields.)

    6) FYI - I just tried changing the share's setting so it does NOT make use of the cache drive.  When I set MIMIMUM FREE SPACE to 500GB, it changes to 8.5%.  8.5% of 6TB is about 500GB.  Seriously, this change to percent is VERY non-intuitive/confusing.

     

    Please be sure to clarify what happens at item 4a above . . . 

     

    Thanks for listening and responding.  I'm sure the change to this field was put in place with all good intentions, but I think (in my humble opinion) that it should be put back the way it was.

     

     

    Link to comment
    JorgeB
    On 7/19/2023 at 8:51 AM, itimpi said:

    As I have been reading this thread, if you currently have files on a cache disk then the % displayed will be relative to that pool? 

     

    If mover then moves the files to the array so there are no files longer on the cache pool I assume the % displayed will now change to be relative to the smallest array drive that is part of the share?

     

    Assuming that is correct then I can see how users will get confused when this % value appears to change without them making any change.

    I agree, I asked for this to be changed to an absolute value to avoid user confusion and for next release it should be back to that.

    • Thanks 3
    Link to comment
    JorgeB
    4 hours ago, RobertP said:

    1) I want to be sure no file writing happens if the drive that initially gets picked has less than 500GB (like it used to work before) - I don't want the "write/no-write" decision (a.k.a. pick another drive) to be

    Nothing changed regarding that, just the value shows up as a percentage instead of an absolute value, but like posted above it will go back to an absolute value once v6.12.4 is released.

    • Like 1
    • Thanks 2
    Link to comment
    RobertP

    @JorgeB - Thank you, thank you, thank you.  Glad it will be changed back, the original way (absolute value) is MUCH more understandable (in my humble opinion).

    Link to comment
    dhenke1690

    Seems like the minimum free space should be storage (i.e. Primary vs Secondary) dependent. I would like to leave 500GB free on my 12TB drives in the Secondary Storage but I don't want to leave 500GB free on my primary storage which is an SSD cache drive. Is there a way to do that?

    Link to comment
    itimpi
    2 minutes ago, dhenke1690 said:

    Seems like the minimum free space should be storage (i.e. Primary vs Secondary) dependent. I would like to leave 500GB free on my 12TB drives in the Secondary Storage but I don't want to leave 500GB free on my primary storage which is an SSD cache drive. Is there a way to do that?


    Unfortunately not.   It has been suggested quite a few times as being desirable but nothing has materialized.. 

    Link to comment


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.

    ×

  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.

    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.