Why are you always dodging questions instead of answering them?
I am honestly confused on what your stance is on these things, because it seems like you can’t be bothered to engage with the questions at hand.
Do you know what’s a prime example of the Dunning-Kruger effect?
People who talk about the Dunning-Kruger effect (because the people who talk about said Dunning-Kruger effect tend to ONLY talk about the left-half of said plot, and often times, completely fail to realise that there is an entire right-half of the plot where there is a high degree of confidence that correspond to the likewise, high degree of competency.
Y’all tend to (and like to) forget that the right side of the plot even exists whenever you people bring it up.
(And yet, you still can’t disprove the arithmetic.)
Quite literally, 4 days later and you still can’t disprove my arithmetic.
LOLLL…
You can only “discount” it, with a blanket statement, a la:
but you still can’t come with the mathematical proof that clearly shows that my arithmetic is wrong.
With your blanket statement, that’s your “cop out” because it’s something that you disagree with, but you can’t prove why you disagree with you, by disproving my arithmetic.
Four days later, and you still disprove my arithmetic.
(This, by the way, is how you can tell that the arithmetic is solid. If there was a problem with it, you would’ve caught it immediately. It shouldn’t take you four days+ to find an error with my arithmetic.)
Like I said, this just goes to prove that you have ZERO interest in how ZFS works, and 100% interest in being right (because you can’t disprove my arithmetic).
You can only make blanket statements that have no arithmetical support/backing.
And yet, you still can’t answer why padding is needed, when degenerate/sub-sized blocks are already permitted.
(It’s already p+1, per Matt Ahrens presentation, unless, of course, you’re saying that what Matt Ahrens’ showed in his presentation, is wrong. At which case, now you’re arguing against Matt Ahrens, to which I say, good luck with that.)
Your arithmetic is not wrong. Your assumptions on sector sizes and ashift are. That is why your red circles are in the wrong place.
Sure I can and I have. It is needed so there are no free space empty sectors that are so small, that it is impossible to write a stripe into it. That is where the p+1 rule comes from. It is pretty clear if you understand how ZFS stripes work.
Why are you such a fan of argument from authority?
Anyway, of course I don’t argue against Matt, because I agree with Matt. The only one here not agreeing with Matt is you, because you are misunderstanding what he is saying.
Anyway, I think I have showed you again and again, that I try discuss in a good faith manner.
You on the other hand don’t seem to be really interested in a good discussion or unable to stay on the topic or answer the questions at hand.
Which is really exhausting, because I 99% of the time don’t even know your stance on something and if you even disagree with me or not.
So unless you are willing to engage with the questions, I am not willing to further discuss anything with you.
- RAIDZ2 with 8 drives, ashift=12, 16k volblocksize, offers 67% space efficiency
- RAIDZ2 with 12 drives, ashift=12, 16k volblocksize, offers 67% space efficiency
Please tell me if you agree with these two. Otherwise I am out. And just be extra very clear, you don’t have to agree with me on these two. I just want to know what your position is.
Again, talk to the author of that spreadsheet if you think they are wrong for calling it “sectors” rather than “ashift”.
I’m not the author of the spreadsheet.
You’ll have to take that up with the author of that spreadsheet that you so proudly cited, initially.
Argue it with him.
I just actually read what he actually, literally, explicitly wrote, back to you.
You think that your disagreement is with me.
It’s not.
Those are his words.
I didn’t create the spreadsheet.
Argue his choice of using the words that he used, with him.
I just cited what he wrote, back to you, and you hate that I did that to you.
But if you allow it to be a sub-size/degenerate block – problem solved. (cf. Matt Ahrens’ example, from his presentation).
(Remember that ZFS already has variable block size.)
Because you’re too chicken to argue against Matt. Me, you have no problems arguing against.
But I tell you to argue your point with Matt, and you’re too chicken to do it.
That’s why.
You’ll claim, all day/all night long, how I don’t understand it.
But you’re not going to argue with one of the architects of the ZFS system, because if you did, you’d lose.
Again, your proving, again, that you’re not interested in how ZFS actually works (because if you were, you’d accept what Matt is explaining to you, about subsize/degenerate blocks, from his presentation and yet, you’re still here, arguing with Matt about his presentation, where he very clearly explains what a subsize/degenerate is and what it looks like, via his pictogram of the ZFS spacemap.
I’m literally citing his presentation to you, where he CLEARLY shows a block with
([P][D])
as the sub-size/degenerate block.
What part of that, from his presentation, don’t you seem to understand?
37:48
allocate one sector of par just for those two sectors of data rather than one sector of par for every three
37:54
sectors of data so you can see that illustrated here the most kind of degenerate case um is like uh so here
38:00
like each color is a different logical block um so like this is the most degenerate case where the data is just
38:07
one single sector and then there's one sector of par so this is like the same space utilization as mirroring right you
What part about this (being a sub-size/degenerate block), don’t you seem to understand?
Matt can’t possibly be clearer.
I am very happy to engage with the point you brought up, after I understand your stance on
- RAIDZ2 with 8 drives, ashift=12, 16k volblocksize, offers 67% space efficiency
- RAIDZ2 with 12 drives, ashift=12, 16k volblocksize, offers 67% space efficiency
Just a simple, yes or no.
Then we can continue.
I see you typing. You don’t have to type so long.
Please, just a simple yes or no.
BWAHAHAHAHAHA…
You literally admitted that you weren’t discussing in good faith.
I’ve already answer you with the arithmetic that you can’t disprove.
Get back to me when you can actually disprove my arithmetic.
The only thing that you’ve got is a blanket statement:
That’s the only thing that you’ve got.
No proof.
No arithmetic.
Nothing.
Just a “he said” statement.
That’s all you have to hang your entire argument over, is only one statement, from you.
Again, it’s not an “assumption”. It is quite literally and explicitly written out for you, which I have already circled for you.
“^block size in sectors”
What part of “sectors” don’t you seem to understand???
That’s not an assumption.
It is literally written there.
That’s because you don’t read, which you have explicitly declared.
See answer here. (I’ve already answered this, four days ago. The fact that you’ve declared that you don’t read, that’s on you.)
If you understand my stance, then why are you still asking the question?
If you understand my stance, then you already know the answer to your question.
That is the thing, I don’t. I really don’t! That is why it is so frustrating discussing with you.
Are you really unable to just say, “no I don’t agree with these two statements”?
Unless you are able to answer questions, I won’t engage any further.
I think I know what your misconception is and I am happy to help you get rid of it.
But you have to be a little bit cooperative.
I will try one last time from another angle.
If we look at the sheet. Take a look this sentence:
The value (parity + padding cost) is shown as a percent of the total storage size. For example, with 7 disks in each RAIDZ1 group, a 16-sector block (8KB or 64KB)
Tell me which numbers you don’t agree with.
- He makes an example of a 16 sector block.
- He states, that a 16 sector block is either 8KB or 64KB
- The reason for number 2. is that he uses the two most used ashift sizes, which are 512 or 4k
- 16 sectors * 512 = 8KB. That is why he claims the block to be 8KB
- 16 sectors * 4k = 64KB. That is why he claims the block to be 64KB
Please don’t bother writing a wall of text. Please tell me what your stance is on these 5 arguments.
Then why would you write
if you don’t understand my stance then???
That make no sense, whatsoever.
See answer here. (I’ve already answered this, four days ago. The fact that you’ve declared that you don’t read, that’s on you.)
[/quote]
You have repeatedly failed to provide any evidence/data/proof for the statement that you are trying to make to try and disprove it, from the very person who created that spreadsheet that you so proudly cited, when you cited it the first time.
All I had to do was to read what it literally and explicitly said, back to you.
That’s all I had to do, was just read (what you cited, back to you).
Says the person who has declared that they don’t read, nor engage.
LOL…
Yeah. Try again.
8192 byte block / 16 sectors = 512 bytes/sector
So, what’s the issue then???
NO!
The reason for (2) is because that’s the sector sizes of drives (whether it’s hard drives or solid state drives).
Again, the OpenZFS documentation explicitly tells you this.
The ENTIRE concept of alignment shift comes FROM drive sector sizes.
Again, the OpenZFS documentation explicitly tells you this.
The alignment shift was created to deal with cases where drives would misreport the drive sector size.
Again, the OpenZFS documentation explicitly tells you this.
Read the OpenZFS documentation about alignment shift, what it is, again.
Slower, and more carefully this time.
It literally and explicitly tells you everything that you need to know and answers all of the questions that you’re asking me.
Read.
Ok, that is good progress. You already agree to most of it.
Let me try again.
- He makes an example of a 16 sector block.
- He states, that a 16 sector block is either 8KB or 64KB
- The reason for number 2. is that he uses the two most used sector sizes of drives, which are 512 or 4k
- 16 sectors * 512 = 8KB. That is why he claims the block to be 8KB
- 16 sectors * 4k = 64KB. That is why he claims the block to be 64KB
Edit: Ahh I see where you are coming from. And where your confusion is coming from.
Sure, the block size can be variable. It can be 16k or it can be 22k or whatever.
But the doc clearly states this:
for blocks of various sizes (in sectors, after compression).
So for now, we go with the example of 16 sectors after compression.
These 16 sectors can either be 8k or 64k.
You agree with that?
Your interpretation of the spreadsheet is wrong. That’s because you fail to read what the spreadsheet author meant by a “sector”.
You also failed to accept my explanation that (without me realising you made the wrong interpretation first) the “sector” in the spreadsheet should be read as “ashift”.
I suggest both of you should stop at this point. It’s not going anywhere. Apparently both made mistakes in arguments due to misunderstanding, imprecise wordings, incorrect jargons (? I don’t know I don’t care).
2 Likes
Any idea why it’s 44 % and not 50 %? When I try to do the math myself I apparently get it wrong somehow:
raidz2, 4 drives, ashift=12, 16 KiB blocks:
- total stripe width is 4
- one stripe can have up to 2 data parts of 4 KiB size (8 KiB total) because of 2 parity blocks (one stripe = PPDD)
- we will have 16 KiB/8 KiB = 2 stripes with 8 KiB of data and 8 KiB of parity each
- 2 stripes each of 16 KiB total size, means we write 32 KiB to store 16 KiB
No padding should be necessary as far as I understand (all blocks are at least 1+P = 3 sectors in size). So why 44 % and not 50 %?
Edit: As explained below, padding is per block (not per stripe) and padding is done to a multiple of (1+p). Not sure what I was thinking here. 
2 Likes
Exactly. You get a stripe like this:
P P D D.
Not to get to your 16k, you would need two such stripes.
P P D D
P P D D
That is 8 blocks total.
Without padding this would be 50%.
But there is padding needed.
8 / 3 = does not work
So you add one padding
9 / 3 = works.
Now you have 9 sectors to store 4 sectors of data.
That is 44%
Side note: We could think about why padding is even needed. Could we not just always use 16k, and because of that always get
P P D D
P P D D
and so there will never be the need for padding, since every stripe is like this? That would be like traditional RAID behaves.
Sure, but the thing is we don’t always get 16k. Not even for a volblocksize 16k, because of compression. So instead we have different stripe sizes, because like alpha rightfully said
ZFS has a variable block size.
From the example above, these two stripes
P P D D
P P D D Padding
form a block with the 36k allocation size.
The provided blocks is 16k in size.
This is something else that might be confusing, the Google Sheet is not talking about the size of the block provided (or volblocksize) it is talking about how big the data itself is. In sectors, after compression.
By using “in sectors” the author of the sheet is able to offer the same sheet for 4k and 512. IMHO it would be less confusing, if he made two separate sheets, with two different ashifts and
“used block size in bytes”
instead of
“block size in sectors”
on the left.
1 Like
Ah, of course, the padding is per block, not per stripe. 
Thanks!
1 Like
But the number of sectors, as shown, can be anything. It can be 2 sectors. It can be 1 (for data, before parity). It can be 14.
Again, the spacemap that Matt shows, it can literally be anything.
Therefore; you repeatedly trying to come back to 16k can be equally valid and invalid, simultaneously.
Why 16k? Why not 32k?
Let’s go with 32k then, given the case.
Or how about 128k (because that’s the actual default recordsize for ZFS, unless you explicitly change it).
Let’s talk about this from the 128k recordsize perspective.