4 ms·

Thanks for the effort, but this is not very convincing. Is there any documented case where physical blocks have size that in bytes is not some power of 2? I sus

• still_grokking 4y ago
  > Thanks for the effort, but this is not very convincing. I've written this to shed light on the alignment issue as I was under the impression that this would be be something completely new to you. ("This sounds interesting. What are these alignment issues?") > Is there any documented case where physical blocks have size that in bytes is not some power of 2? Yes, there are examples online. I did not make this up! It was in fact some major WTF as I came across it… > I suspect if that exists, it is quite a rare device. Jop, that for sure. Also the documentation is very spare on this, like already mentioned. I think it was the early triple-cell chips that had such crazy layouts. (Did not look it up again; maybe this was only a temporary quirk; but maybe it still exists, no clue). > Blocks of size 512B, 4K, 8K are the most common case, and correct alignment is completely taken care of by the 1MiB offset which is standard and default in fdisk and similar tools on Linux. Well, it depends. This thingies I've read about with some factor of 3 in their block size would need at least a 1.5 MiB offset… (And the default 1 MiB offset would torture them to a quicker death; but most people would likely never find out). There are devices with much bigger (optimal) block sizes, I think in the MiB ballpark (don't remember the details out of the top of my head, would need to look it up again myself). Also in such cases the 1 MiB would not suffice. Those devices are usually in some compatibility mode in factory settings, with much smaller blocks than optimal for maximal performance and least wear. You need to tell the firmware explicitly to switch the block size to get best results (which is of course not possible after the fact as it obviously shreds all data on the device). Also it's not only the offset around the partitions. You need to take the block sizes into account also regarding the block layers "inside" the partitions. Which was actually my point: This makes things more complicated than strictly needed. > You mention "random" offsets with newer Unix tools - I have never encountered this. Any examples? By "random" I've meant that the offsets appear seemingly random when you don't know the underlying issue. It's not only the one offset after the partition table. Depending how large the partitions are there may be or may not be additional offsets around the partitions themself. Of course all this is not rocket science. We're talking about simple calculations. But that's just one more thing to be aware of. My conclusion form that journey back than was: Just screw it, and don't add partitions to the mix if you don't strictly need them. One thing less to care about! For example the laptop I'm just writing on has two NVM devices. The bigger and faster one is used as (encrypted) root FS, without any partitions on it, the other smaller and slower one carries the EFI partition and an (encrypted) data partition. If I would have have partitions on the root disk this would not give me any advantages, but additional stuff to think about. So why should I do that? OTOH I need an EFI partition to boot. So I have created one on the other disk. I think this is a very pragmatic solution. Just don't add anything that you don't need. <insert Saint-Exupéry quote about perfection here>
  • effie 4y ago
    Alright that makes sense.