RobertP
-
Posts
52 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by 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.
-
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. -
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.
MINIMUM FREE SPACE changes to a (bogus(?)) percentage
in Stable Releases
Posted
@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).