Re: Adding an ioctl to check for disklabel existence
On Oct 2, 9:47pm, Mouse wrote: } } >> If _that_'s what you're concerned about, then just grow the relevant } >> fields (and, presumably, change the magic number). } > Any change to the label format or semantics would make it be a } > completely different object, no longer compatible with anything. } } Of course. } } > If we were going to invent something new that way, we may as well } > make it lots better - and ideally compatible with other systems so we } > can read one another's drives. } } > That's what GPT is, and it is already supported. } } Except for the "better" part, which is a matter of opinion. I don't } care for GPT. } } - Partitions are huge. 128 bytes, when you actually need maybe 18 (and }about a quarter of even that is pure future-proofing paranoia). I assume that you're talking about the size of a partition entry here. The size might be somewhat wasteful, but on a multi-terabyte drive isn't a particularly large concern. } - Partition types are UUIDs. Why use 16 bytes when you have, in the }information-theoretic sense, maybe three bits of information? }(At least, I can't recall the last time I used a partition type }other than FFS, unused, swap, MSDOS, or NTFS - and NTFS only for }trying to figure out what's on Windows disks. Six bits, maybe, }based on doubling the number of types I see in disklabel_gpt.h. My }"18" above assumes 16 bits.) I have 38 types in my list, which I'm sure is incomplete. That's a bit more than three bits. When the space is small compared to the utilisation, collisions are highly likely. Anybody can generate an UUID and if done properly the likelihood of collisions is very small. This would be the obvious reason for using an UUID. Remember that GPT is a standard meant to be used by all operating systems on multiple platforms } - Partition names(!) are character strings, rather than octet strings }or integers (an encoding is specified). This mandates a lot of }character-handling crap that does not belong in boot blocks and }arguably does not belong in operating systems. It most certainly is }not appropriate for the partition table format to mandate/demand the }presence of Unicode support in the operating system. } } It does have one nice thing, a (supposedly-)unique partition } identifier. (Of course, nothing can ensure this actually _is_ unique; } if nothing else, cloning an entire disk will perforce clone these } `unique' IDs.) But it doesn't need to be 16 bytes long! Even adding } 14 bytes of partition ID to the 18 bytes above still comes out to only } a quarter of the space GPT burns on each partition. Cloning disks always presents issues. However, gpt(8) has grown a "uuid" command to generate new UUIDs. This was primarily done to help with the cloning problem. Cloning a disk and then putting two disks with the same UUIDs on the same system is an operator error. } > Why would we want to invent something new, just to be different? } } No, not to be different. To be better. Ah yes, https://xkcd.org/927/ } Except, of course, that (I assume) you don't think it _would_ be } better. Better or not better is not really the point, being incompatible for specious reasons is. }-- End of excerpt from Mouse
Re: Adding an ioctl to check for disklabel existence
>> If _that_'s what you're concerned about, then just grow the relevant >> fields (and, presumably, change the magic number). > Any change to the label format or semantics would make it be a > completely different object, no longer compatible with anything. Of course. > If we were going to invent something new that way, we may as well > make it lots better - and ideally compatible with other systems so we > can read one another's drives. > That's what GPT is, and it is already supported. Except for the "better" part, which is a matter of opinion. I don't care for GPT. - Partitions are huge. 128 bytes, when you actually need maybe 18 (and about a quarter of even that is pure future-proofing paranoia). - Partition types are UUIDs. Why use 16 bytes when you have, in the information-theoretic sense, maybe three bits of information? (At least, I can't recall the last time I used a partition type other than FFS, unused, swap, MSDOS, or NTFS - and NTFS only for trying to figure out what's on Windows disks. Six bits, maybe, based on doubling the number of types I see in disklabel_gpt.h. My "18" above assumes 16 bits.) - Partition names(!) are character strings, rather than octet strings or integers (an encoding is specified). This mandates a lot of character-handling crap that does not belong in boot blocks and arguably does not belong in operating systems. It most certainly is not appropriate for the partition table format to mandate/demand the presence of Unicode support in the operating system. It does have one nice thing, a (supposedly-)unique partition identifier. (Of course, nothing can ensure this actually _is_ unique; if nothing else, cloning an entire disk will perforce clone these `unique' IDs.) But it doesn't need to be 16 bytes long! Even adding 14 bytes of partition ID to the 18 bytes above still comes out to only a quarter of the space GPT burns on each partition. > Why would we want to invent something new, just to be different? No, not to be different. To be better. Except, of course, that (I assume) you don't think it _would_ be better. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Adding an ioctl to check for disklabel existence
Date:Wed, 2 Oct 2019 10:48:26 -0400 (EDT) From:Mouse Message-ID: <201910021448.kaa25...@stone.rodents-montreal.org> | If _that_'s what you're concerned about, then just grow the relevant | fields (and, presumably, change the magic number). Any change to the label format or semantics would make it be a completely different object, no longer compatible with anything. If we were going to invent something new that way, we may as well make it lots better - and ideally compatible with other systems so we can read one another's drives. That's what GPT is, and it is already supported. Why would we want to invent something new, just to be different? | Or fix sector sizes other than 512 bytes. disklabels work fine with drives with different sector sizes, and scale the size limit proportionally, but only on drives with different sector sizes. There was a fad for making drives export bigger sector sizes for a while, mostly, I suspect, because MBR has the same limitation as disklabel does. Now GPT is widely available, everything seems to be back advertising 512 byte sectors again (regardless of whatever happens to be the way the physical drive is used - which with caching, and likely full track reads most of the time, is difficult to observe externally). kre
Re: Adding an ioctl to check for disklabel existence
> however, disklabel fails at >2TiB for 512 byte sector, If _that_'s what you're concerned about, then just grow the relevant fields (and, presumably, change the magic number). Or fix sector sizes other than 512 bytes. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: COMPAT_NETBSD32 broken on aarch64 due to UVM bug
On 2019/10/01 18:46, Jared McNeill wrote:
On Mon, 30 Sep 2019, Rin Okuyama wrote:
http://gnats.netbsd.org/54395
With the patch attached in the PR, that KASSERT does no longer fire on
aarch64 with 32-bit binaries, as far as I can see. Also, the patched
kernels just work for me on amd64, earm, and m68k.
I have been running with the patch in this PR doing bulk builds on arm64 for
both arm64 and armv7 in parallel and the KASSERT no longer fires for me either.
Nicely done!
Thank you for testing the patch!
I updated the patch in accordance with comments by uwe and joerg:
http://www.netbsd.org/~rin/uvm_map_20191002.patch
Here's a summary of changes --- mostly no functional changes:
- Turn ALIGN_VA() macro into inline function align_va().
- Use proper macros, round{up,down}2(9).
- Make sure that alignment is power of 2 in uvm_map_space_avail().
I will commit the revised patch, and send a pullup request in
the weekend, if there's no objections.
Thanks,
rin
