Recommended changed to the new V7.0 status output
A backup program for disk arrays
Brought to you by:
amadvance
Menu
▾
▴
In the latest 7.0 beta (2014-10-25)
The status command gives the following output in a table:
Edit: There is also a Use and Name column on the right side of the table above but the forum seems to eat it up for no good reason...
I think it should be changed to this:
Edit: There is also a Fragmented Files column on the right side of the table above but the forum seems to eat it up for no good reason...
Parity GiB shows how much space in parity file is required by the data.
The available GiB column show how much room is left on disk with respect to parity.
If parity size + available disk space on the parity disk with the least space left) is smaller than free space on data disk then it should show free space on data disk minus Parity GiB.
Even better of course if it also considered estimated waste on the available space.
Free space needed shows minimum free space required on the data disk. Basically this is your original waste column with different name, but if possible it should also include estimated additional waste.
Excess fragments and free% didn't feel relevant enough to keep. Fragmented files could still be relevant in cases of extreme fragmentation.
If implemente it should really be much more intuitive and informative for both new and experienced users.
Bringing back Parity size on a separate line (as in 6.3) after the table would also be good.
Last edit: Leifi Plomeros 2014-10-25
By the way, there is one thing we certainly agree on. The actual parity file(s) size should be reported in the status command.
Also, the "wasted space" or the "holes size" in the parity file should be reported. This would be the difference between the actual size of the parity file and the blocks GiB size of the data drive with the most allocated blocks.
There definitely should NOT be a column labeled "Parity" since that extremely misleading. No single data drive "requires" space in the parity file. The parity file is made up of a combination of data from the data drives.
The über-correct label would be:
"The amount of space, shared or not shared, required in the parity file by the data currently stored on this disk"
The problem is that it is a bit too long and needs to be shorter.
So I suggest that it is simply called Parity GiB and put next to Data GiB, so that it is easy to understand the relationship.
Please clarify the possible misinterpretation.
Will someone suddenly think that his 4 TB disk will now have room for 3500 GiB x 2 + some more and also think that the extra space is used to store parity instead of the parity disk(s) he has defined in the config file?
I would also think that the free space needed column and the available column would help avoiding such interpretations...
Last edit: Leifi Plomeros 2014-10-25
Or, the actual correct label would be "Blocks"
I'll clarify the misinterpretation. The data drives do not contain parity. The data on the data drives are used to compute the parity.
There is a single number that represents the size of the parity file(s). In most cases, it will be equal to at most one of the numbers in the column that would be properly labeled "Blocks".
Last edit: jwill42 2014-10-25
Yes, but the goal was to be intuitive and informative, both to new and experienced users.
What possible use do you have for knowing the number of blocks? The first thing you are going to do with that number is to multiply it by block size... And the next thing is to put the result in relation to something else.
To me that seems just about as usueful as replacing GiB with GiBit so that we can see exactly how many bits are stored on disk, because we don't really store bytes there, only bits.
We just discussed this in the other thread. At no time in that thread did I propose listing the number of blocks. What we discussed was "Blocks GiB", which is the number of blocks multiplied by the size of a block.
As for intuitive and informative, labeling the column as "Parity" would be both non-intuitive and non-informative, since it is misleading and incorrect. It would also be confusing to new users, since they would see a bunch of different numbers labeled "Parity" and some will wonder if those are the sizes of the different parity files, or if they have single parity, they might wonder which is the size of their parity file.
Call a spade a spade, not a horse.
Last edit: jwill42 2014-10-25
Sorry for misunderstanding. But still...
I read you like this:
There should be a column labeled: Parity required as dictated by number of blocks, presented in GiB, with shortname Blocks GiB.
I don't see that it adds any value compared to:
Parity required, presented in GiB with shortname Parity GiB.
An experienced user who knows about parity blocks, should have no problem translating the latter to the former.
A new user may have problem translating the former to the latter.
In the end the only thing the reader needs to understand is:
If you have "this much" data then you need to have at least "this much" parity.
Last edit: Leifi Plomeros 2014-10-26
No, do not put words in my mouth. I said exactly what I meant.
You continue to mislead and confuse the issue.
I'm sorry that you feel that way.
I promisse that I had no intention of misrepresenting you or misleading in any way.
But surely you would agree that, an experienced user will understand what the number represents in both alternatives?
And I assume that you do not see anything technically wrong in the statement that a certain amount of data requires a certain amount of parity?
Do the new user really need to know that the parity is built on blocks? Isn't it enough to know that it is slightly bigger than data and to be able to see how much bigger in the status output?
Then in the FAQ there could be a few posts to clarify for the user who wants to know more like this:
Why is parity bigger than data?
Because blocks...
Can I make parity smaller?
Yes...
Is the amount of needed extra space for parity cumulative for each data disk?
No...
Please stop misrepresenting what I am saying. I certainly do not agree with the misleading statements you persist in making.
Once again -- as I have said several times already -- the column we are discussing is extremely simple.
SnapRAID allocates a definite number of blocks for the data on each data drive. The "Blocks GiB" column is simply the number of blocks allocated multiplied by the size of a block. That is what it is, no more, no less.
Labeling the column "Parity" would be extremely misleading, since it is NOT parity.
Call a spade a spade, not a horse.
Last edit: jwill42 2014-10-26
It is the required parity size for the amount of data.
It is not re-branding a spade into a horse, it is only saving a few characters in the label. Very much like Block GiB.
No, that is incorrect. It is the size of the blocks allocated for that data drive.
No matter how many times you call a spade a horse, in reality it is still a spade.
I think Parity GiB is correct, intuitive and not misleading.
You do not agree.
I suggest that we leave it like that.
This is not a matter of opinion on which you can disagree. You are simply incorrect. It is as if you said, let us call all the data drives as parity drives. The experienced users will figure out what we mean. And for the new users, we can just explain that when we say parity drive, we really mean data drive. Absurd.
A spade is a spade, not a horse.
Last edit: jwill42 2014-10-27
Your failure to understand something which I have repeatedely clarified, does necessarily mean that others will also misunderstand.
It is really as simple as horizontally stacking books in a box. The widest book determines the required width of the box and each book has a required box width.
No, wait. That is incorrect and misleading! Someone might get the wrong idea and think that the book is the box!
The width of the book is determined by the width of the cover of the book which is a result of the pages of the book! Therefore we must label it page width!
Brilliant! Now get of your high spade.
You persist in posting nonsense. It is completely absurd to call the data drives "parity drives", just as it is absurd to call data blocks "parity".
A fact is a fact, a spade is a spade, and you are simply incorrect. This will not change no matter how many times you claim a spade is a horse, nor how many times you pretend to stop arguing and then continue to post nonsense.
I have not called data drives parity drives.
I completely agree that it would be absurd to do so.
This is why it is so absurd of you to keep arguing based on your absurd misunderstanding.
A data file is a data file.
A data disk is a data disk.
A parity disk is a parity disk.
A parity file is a parity file.
A spade is a spade.
A horse is a horse.
This has never been disputed.
The only thing in dispute is whether or not it is intuitive to label the required parity size for each individual data disk as Parity GiB.
You think that it is misleading. I disagree.
Last edit: Leifi Plomeros 2014-10-27
You persist in posting nonsense. You have repeatedly called data blocks "parity", which is completely absurd. Just as absurd as calling data drives "parity drives".
A fact is a fact, a spade is a spade. No matter how many times you try to obscure the facts, the facts remain the same. You are simply incorrect.
Really? Could you please provide a quote where I do this?
Every post.
So why can't you quote me doing it then?
Are you on drugs?
No, but I am fascinated by the fact that you cannot admit when you are wrong and amazed that you are unable to find a single quote, when there should be one in every post...
So you are no longer claiming that you want to label the data blocks as "parity"?
How does that make me wrong? Clearly you were repeatedly wrong, over and over, and then you suddenly realized your mistake and now want to blame it on me?
If you are not on drugs, perhaps you need to be. ;-)