Alpha you are engaging in such a bad faith, and twist my words around, that I am not really engaging with what you write. I just pick random parts to quote you, because it is so much fun
There you go. But I guess this isn’t good enough for you, because I can’t offer you a WD drive with 512n in its name.
Because that is a pretty good default?
rw amplification and fragmentation if your VM makes smaller writes than 64k.
Yes, because there are so many 512b drives nowadays /s
And yes, because it is a great idea to get a 512b drive and use an 4k ashift, instead of using ashift=9 and not suffering that much from the efficiency problem, because, well you use ashift 9 and not 12
Ahh, now I see where your confusion comes from.
To get serious again for a moment, I am sorry to tell you, that this is not how it works.
If you have a 512b drive and set shift=12, you set the sector size to 4k, the math is exactly the same as a for a 4k drive. The only thing that changed, is that the drive isn’t using the native size.
Or to say it differently: For a 16k volumeblock in this RAIDZ2 with ashift=12 and 8 drives wide, it would still use 4k blocks that are P P D D D D. So you still use 6 sectors (24k) to store four data sectors (16k), which results in 66% (or 33% costs, if you use it the other way round, like in this sheet)
So no, you don’t end up with 32 drive sectors (well you do internally end up with 32 native drive sectors) but from a ZFS perspective you end up with 4 sectors.
You use 4k ashift. How much 4k do you need to get the 16k of your volblocksize? Correct it is 4.
So in your sheet, you don’t end up in the row 32 but in the row 4.
Yes, these 4 sectors that are 4k, use internally 32 sectors.
4 sectors * ( 4k / 512b) = 32 sectors.
But this has nothing to do with ZFS or storage efficiency.
Sure, if I don’t want bad, but super bad performance, that is a great idea
As a bonus you get fragmentation from hell, which results in horrible resilver times, which gives you the opportunity to complain in forums about ZFS resilver times, compared to HW RAID. Win win win
But jokes, nitpicks, fun, misunderstandings and misrepresentations aside for a moment:
If we go back the statements, could you please answer me if you also agree with the last two statements? I made it more clear by specifying the drives sectors sizes (not that it matters, as explained above, but just to make it simpler, we use 4k).
RAIDZ2 with 4 drives, offers 50% RAIDZ2 with 8 drives (4k native), ashift=12, 16k volblocksize, RAW VM disk, offers 66% storage efficiency RAIDZ2 with 12 drives (4k native), ashift=12, 16k volblocksize, RAW VM disk, offers 66% storage efficiency
If that was true, you wouldn’t be here, b!tching about it.
Sounds like another b!tch point to me.
If volblocksize is > 16k, you b!tch about rw amplification and/or fragmentation if your VM writes are less than the volblocksize, but greater than 16k. But if the volblocksize is <= 16k, then you b!tch about the space efficiency.
Sounds to me like you just want to b!tch for the sake of b!tching.
eBay has listings like this here, here, and here such that between those three listings alone, you can buy 30 drives (or more) where those drives have and use 512b physical sectors.
Top-level vdevs contain an internal property called ashift, which stands for alignment shift."
The OpenZFS documentation is very clear about this.
The same OpenZFS documentation also explicitly tells you why the alignment shift is needed, quote:
"In an ideal world, physical sector size is always reported correctly and therefore, this requires no attention. Unfortunately, this is not the case. The sector size on all storage devices was 512-bytes prior to the creation of flash-based solid state drives. Some operating systems, such as Windows XP, were written under this assumption and will not function when drives report a different sector size.
Flash-based solid state drives came to market around 2007. These devices report 512-byte sectors, but the actual flash pages, which roughly correspond to sectors, are never 512-bytes. The early models used 4096-byte pages while the newer models have moved to an 8192-byte page. In addition, “Advanced Format” hard drives have been created which also use a 4096-byte sector size. Partial page writes suffer from similar performance degradation as partial sector writes. In some cases, the design of NAND-flash makes the performance degradation even worse, but that is beyond the scope of this description.
Reporting the correct sector sizes is the responsibility of the block device layer. Since many devices misreport their sector sizes and ZFS relies on the block device layer for this information, each platform has developed different workarounds. The platform-specific methods are as follows:"
The OpenZFS documentation for alignment shift, continues:
“-o ashift= is convenient, but it is flawed in that the creation of pools containing top level vdevs that have multiple optimal sector sizes require the use of multiple commands.”
Again, read.
No, that is not how that works.
If the Google spreadsheet wanted to report the numbers based on alignment shift, it would have stated, quote:
They literally couldn’t have made that spreadsheet more explicit for you, where they literally spell it out for you, that it is expressed in sectors, not ashift.
Read.
cf. my remark about you b!tching for the sake of b!tching above.
(By the way, you’ve already proved that you can still get free space fragmentation from using ashift=12 with 4kn/512e drives as well.)
It’s not a misrepresentation.
The spreadsheet explicitly tells you that the “^block size in sectors”.
You are the one who is choosing to ignore what has literally been spelled out for you, explicitly, by the author of that spreadsheet.
Even the OpenZFS documentation about alignment shift also literally and explicitly spells it out for you about what it is. As a result of them doing that, it also implicitly spells out for you what alignment shiftisn’t. But again, given that you don’t read, of course you would completely ignore the fact that by explicitly telling you what alignment shiftis, that it also tells you what alignment shiftisn’t.
Read it again, genius.
You’re literally proving my point for me:
You’re not actually interested in the details, nor the merits of the discussion.
What you’re actually looking for is an echo chamber/bubble, someone who will be a “yes man” to your B$.
You don’t want to be wrong.
And you most definitely don’t want to read, nor learn, nor improve your understanding of the material/subject matter at hand.
Like I said, I don’t even need to prove that you’re wrong.
Your own sources and citations are already doing that for me.
I just have to cite your own sources and citations back to you, and then circle/highlight the parts of your own sources and citations where your own sources and citations disprove your own statements and comments, inherently.
In cartoons and animations, you’d be Wile E. Coyote, where you’re trying to pull back on a tree branch, trying to hit me with it, and instead, you just end up hitting yourself.
This is exactly and precisely what’s happened here.
You literally had to change your original statements/question JUST to make what you’ve been saying all along, fit/work for you, rather than learning from the fact that your original statements/questions are wrong, which I have already proved, time and time, and time again, without even trying.
And if you have tochange your question/statementsjust to make your argument work for you, then Son, you lose!
Perhaps it’s better to just let him be wrong and get on with your life? I’m not sure if he’s trolling or not, but either way it’s apparent that the more you try to set him straight the more misinformation he writes. You can’t teach someone who isn’t listening. Plus the toxicity…
Translation:
You can’t actually defend your own argument on its own, technical merits, which is why you have to resort to this.
I know.
I’ve already stated numerous times, that you don’t read.
You have consistently provided the data and the evidence to support this point.
I don’t need to.
It is literally from the very sources that you cite, and I literally just put red boxes/circle the words/phrases, in red for you, because you have repeatedly provided the data and the evidence that you don’t read.
This is why you are losing (this argument).
I don’t need to twist your words around, not when the words are explicitly and literally spelled out for you, from the very sources that you, yourself, cite.
Quite the contrary, I literally pick apart your entire argument, one piece at a time, and prove how your argument is incorrect, again, using the very sources that you cite.
I have repeatedly proved where, when, how, and why you’re wrong, and time and time again (like I said, due, in no small part, because you don’t read), and if this was a real debate, you’d recognise all the times where I’ve gotten you to change course, in your argument, because I successfully made my point against your point of argument(s).
But that isn’t what you’ve done.
So pursuant to the explanation of what a bad faith argument is, it would appear: “kettle, meet pot”. (i.e. you’re doing precisely and exactly the same thing that you accuse other people of doing, which is the tu quoque logical fallacy, in and of itself.)
You want to improve someone else’s response to you, you can start by changing the way that you are engaging (or apparently, you’re not even engaging, per your own admission) in this argument/debate.
But if you’re going to, outright, declare that you aren’t really engaging with what I am writing (which I have already noted, a bunch of times on this thread and on the other thread(s) already), then why would you be accusing others of “engaging in bad faith” when you, yourself, literally in the next sentence, declared that you’re not really engaging with what I am writing anyways?
I am 100% certain that you have never thought about how you end up getting exactly what you serve/dish out.
That’s just called karma.
Interestingly enough, neither of you have been able to disprove the arithmetic.
You call is misinformation, and yet, the words that were specifically chosen to be used in the very spreadsheet that @ThisMightBeAFish cites (along with the OpenZFS documentation), very clearly states what it is, explicitly and literally.
So, if you want to argue with me about it, now you are arguing with the person who created said spreadsheet to begin with (which @ThisMightBeAFish has cited and/or referenced, repeatedly thoughout this and his other threads), as well as you’re now arguing with the OpenZFS documentation, to which I say, good luck with that.
You guys write about alignment shift (i.e. ashift) as though it is the same as sector size, but the OpenZFS documentation clearly explains that alignment shift is not the same as sector size, but rather to align with the (physical/logical) geometry of the drive, hence the name alignment shift.
If you think that I’m wrong about that, take it up with the maintainers of the OpenZFS documentation.
Yeah, but the block size in sectors is 4, if you set ashift to be 4k and you want to write 16k.
The whole docs says nothing that is relevant to our discussion or contradicting to what I wrote.
I love to be wrong That way I can learn from my mistakes.
I would have given up a long time ago, but the thing is, what if I am wrong and he is right?
But to be honest, I am not even sure if he even disagrees with me on the relevant and real world examples. I am not really interested in strange edge case like 512e.
I bet he also agrees with the last two:
RAIDZ2 with 4 drives, offers 50% RAIDZ2 with 8 drives (4k native), ashift=12, 16k volblocksize, RAW VM disk, offers 66% storage efficiency RAIDZ2 with 12 drives (4k native), ashift=12, 16k volblocksize, RAW VM disk, offers 66% storage efficiency
If your drive sector size is 512b, and the block size, in sectors is 4, then 4 * 512 bytes = 2048 bytes.
If you set your ashift=12, then what you are telling ZFS is to do is to align the geometry of ZFS such that one ZFS record takes two blocks, with each block being four 512b sectors wide.
Therefore, if [] is a drive sector, () is a block of n-drive sectors, || is the ZFS alignment shift, and {} is the ZFS record, then you would get this:
{|([][][][])([][][][])|([][][][])([][][][])|}
That is what that would look like if a drive sector is 512b, block size in terms of number of drives sectors =4, alignment shift=12 (4096 byte ZFS alignment).
What is shown above is two ZFS “records” of that.
If the recordsize for your ZFS dataset is the default 128k, then you’d get this:
(Again, this assumes a fixedrecordsize, but as we have already covered extensively, ZFS doesn’t used fixed recordsizes, but rather has variable recordsize for efficient (mostly) space allocation, per Matt Ahrens.
You will also note that if you’re doing this for a volblocksize=16k, then it will look like this:
But with a sector size of 512b, for a 16k volblocksize, you still literally have 32 [] (drive sectors) in there, to make up said 16k volblocksize.
Like I said, the spreadsheet that you have cited over and over again, is very clear about this.
The reason why you are still having a hard time, grasping this concept, is because you are still thinking that alignment shift = drive sectors, which is false if the size of the drive sector is 512b.
That still doesn’t change the fact that the spreadsheet itself, literally and explicitly state:
“^block size in sectors”
not
“^block size in ashift”
STOP equating the two. They are not the same thing, as I have explained to you over and over again.
No, you don’t.
There’s literally four threads worth of evidence that disproves your statement here.
"The sector size on all storage devices was 512-bytes prior to the creation of flash-based solid state drives. Some operating systems, such as Windows XP, were written under this assumption and will not function when drives report a different sector size.
Flash-based solid state drives came to market around 2007. These devices report 512-byte sectors, but the actual flash pages, which roughly correspond to sectors, are never 512-bytes. The early models used 4096-byte pages while the newer models have moved to an 8192-byte page."
Again, the OpenZFS documentation is very clear about the 512e case, regardless of whether you’re interested in it or not.
Again, you changed your last two statements just to make your pre-determined worldview/mental model work for you.
The question that you initially posited was this:
And once I proved that when you’re looking at drives that uses 512b sectors, I was able to demonstrate to you, by literally citing the very same spreadsheet that you cited, that your statements are incorrect, pursuant to the arithmetic that follows 512b drive sectors.
To date, you (still) have not disproved said arithmetic, which means that you know that you’re wrong, but contrary to your statement here:
You’re not actually abiding by your statement that “you love to be wrong”.
It’s not even an if question/statement anymore.
I have already provided the data and the evidence, from the very Google spreadsheet, that you have repeatedly cited, and I literally circled it in red for you, what the answer is.
None of your replies, have been able to provide a rebuttal to literally what I circled in red for you, from that spreadsheet.
In other words, your own citation of the spreadsheet is the very document that provides the data and the evidence that you are wrong.
And yet, contrary to your claim of you loving to be wrong, what you actually did, instead, is changed the question, so that it will match what your thinking is, rather than actually learning from you being wrong.
And yes, I also know that as well, but it may appear that I am not certain if @ThisMightBeAFish knows this.
If you’ve been in the computer/IT scene since, AT LEAST the early 2000s, people generally knew that.
(I don’t remember if this was always necessarily the case for hard drives manufactured between 1990-2000, because I remember one of the guys from a computer store that my dad and I went to, he would calculate the drive geometry in his head, based on the number of cylinders, heads, and sectors (CHS). That was the 90s when you had to enter the drive geometry, into the BIOS, for it to work. If you got it wrong, then the system won’t boot. It was such a huge relief when the bigger drives started showing up, and as a result, it would just query the drive for its geometry or it would use logical block addressing (LBA), and then as drives got even bigger still, there were issues where you weren’t sure if systems were using LBA32, LBA48, or LBA64.)
Those were the days.
But yes, 512b drive sectors was the default for a longggg time.
And I absolutely, agree that the whole “512n” nomenclature is more of a backronym type of thing.
The vastly more important question is why is that so important to you, rather than you learning that you were wrong pursuant to your original statements?
What psychological trauma have to lived through such that you are so deseparately seeking approval (or at least, agreement) from someone whom you fundamentally disagree with, as your apparent top priority?
That is the vastly, more important question, by far.
Your question provides further data/evidence that this statement from you, is patently false (because if it were true, you wouldn’t have changed your original question, after the data has been provided to you, which shows that your original question, is wrong – something that you still haven’t disputed nor provided a counterargument against the parts from the Google spreadsheet that you have cited, which I took screenshots of, and then circled the relevant parts in red.)
(With this question however, you at least acknowledge the fact that you changed your questions, to fit your pre-determined worldview/mental model, despite the data and the evidence that has been presented to you, which proves that outside of your pre-determined worldview/mental model, your original question is not true, as shown by me circling the data from the sources that you cited, which showed your statements as being incorrect.)
Jesus, you really get out of your way to not answer the question.
I take this as a yes.
The reason why I would like you to answer the question is that we need to establish some ground truth before we head into the details. Otherwise a discussion is meaningless.
This here:
RAIDZ2 with 4 drives, offers 50% RAIDZ2 with 8 drives (4k native), ashift=12, 16k volblocksize, RAW VM disk, offers 66% storage efficiency RAIDZ2 with 12 drives (4k native), ashift=12, 16k volblocksize, RAW VM disk, offers 66% storage efficiency
is just the start. If we can’t agree on that one, there is no point discussion stuff like
what it means to use cow on top of cow
implications of 64k volblocksize
how 512e are a strange niche better left ignored instead of unnecessary complicate an already complicated discussion
Disclaimer: I didn’t read 98% of this thread’s content, and surely 100% didn’t attempt to follow the logics of debates from both sides. Neither I have guru-class experience in ZFS. But I have pretty solid foundation in Computer Science, so I might have a bit edge in understanding some fundamentals of ZFS. LOL
In old days, ‘ashift’ was always equal to a sector. HDD techs evolved in the past 15-20 years (?). A sector isn’t a sector these days. But the point of what’s a sector is irrelevant in discussion of space efficiency in ZFS. What matters is “ashift”. When you set the “wrong” ashift, it doesn’t affect space efficiency. It just affects read/write speed and write amplification by HDD’s firmware.
The “sector” in “block size in sectors” should be read as “ashift”.
The percentage is overhead of parity and padding. Space efficiency is 100% minus that value.
So now we can reach the conclusion:
RAIDZ2 with 4 drives, ashift=12, 16k volblocksize, offers 44% space efficiency
RAIDZ2 with 8 drives, ashift=12, 16k volblocksize, offers 67% space efficiency
RAIDZ2 with 12 drives, ashift=12, 16k volblocksize, offers 67% space efficiency
Also
is not valid question.
Both occur at the last block of a file. Padding describes the p+1 rule in ZFS. A degenerated block simply describes a block not with its size fully used.
It does, at least for me. It demonstrates that I wasn’t mistaken. That would be perfectly fine with me; I don’t care about being right; I care about understanding how ZFS works.
In the presentation from Matt Ahrens, he points to the block that has only one parity block and one data block from a raidz(1) configuration, and called that a degenerate/sub-size block.
My point is that if that was allowed, then you could permit that even further, such that padding blocks aren’t needed at all, to full the block/stripe.
What you described about “degenerated block” above is not in contradiction with what I said about it.
Your original question is still invalid to me. Also you obviously still don’t understand what the p+1 rule is. Perhaps go back and re-read what’s p+1 rule.
And yet I am still not sure if you have understood or would agree, that the sector size is irrelevant for storage efficiency itself, and only ashift matters in that regard
Ohh and btw, you still have only explicitly agreed with one of my “narrowed down assumptions to fit my worldview” and not the other two.
It really is peak of mount stupid to think that the many ZFS devs just did not work hard enough to come up with a smart idea, so that padding is no longer needed.
Again, if you were actually interested in how ZFS works, you would have at least acknowledged the fact that you were wrong, per your original question as it pertains to the two statements in question.
If the sector size didn’t matter, and only the ashift mattered, then you wouldn’t have revised your question.
But again, that’s not what the arithmetic shows, and you have yet to prove that the arithmetic is wrong in any way, shape, or form.
RAIDZ2 with 4 drives, offers 50%
RAIDZ2 with 8 drives (4k native), ashift=12, 16k volblocksize, RAW VM disk, offers 66% storage efficiency
That way I can learn from my mistakes.
