| opendevreview | tzing proposed openstack/diskimage-builder master: Upgrade openEuler to 22.03 LTS https://review.opendev.org/c/openstack/diskimage-builder/+/927466 | 06:41 |
|---|---|---|
| opendevreview | tzing proposed openstack/diskimage-builder master: Upgrade openEuler to 24.03 LTS https://review.opendev.org/c/openstack/diskimage-builder/+/927466 | 08:35 |
| TheJulia | So, we found a problem with GPT partitioning and dib, or to be more precise with hardware with 4k block devices which only allow use of 4k block devices | 23:33 |
| clarkb | TheJulia: meaning dib would need to partition with 4k blocks ? | 23:49 |
| clarkb | it does already partition aligned to 1MiB by default which should be compatibile with 4k blocks | 23:50 |
| clarkb | is the issue the partitions or the fs block size? I'm guessing it is actually the filesystem within the partitions as we're 1MiB aligned already | 23:52 |
| TheJulia | not alignment | 23:52 |
| TheJulia | it boils down to how GPT works actually | 23:52 |
| TheJulia | on a 512 byte block virtual size system, gpt starts in the second block and ends in like block 35 | 23:53 |
| TheJulia | in a machine with a 4k block size, gpt starts in the second block, and ends in block ?8? | 23:53 |
| TheJulia | that *first* block for 512 starts at byte 512, where as on the 4k device, it starts at byte 4097 | 23:54 |
| clarkb | oh I see | 23:54 |
| TheJulia | meaning the 512 block device is incompatible with the 4k disk storage system | 23:54 |
| clarkb | and then you probably also need xfs/ext4 etc to be 4096 block sizes but that appears to be default for xfs at least | 23:54 |
| TheJulia | well | 23:54 |
| TheJulia | They might be smart enough to figure that part out | 23:54 |
| TheJulia | generally mkfs.ext4 definitely is | 23:54 |
| TheJulia | at least based on testing | 23:55 |
| TheJulia | The issue is partitioning also needs to be sector size aware as well | 23:55 |
| clarkb | ya ext4 appears to use a heuristic but the manpage says it will usually be 4096 | 23:55 |
| clarkb | xfs seems to hardcode 4096 as the default | 23:55 |
| TheJulia | that is good then | 23:55 |
| clarkb | so in theory if we can change the layout of the gpt partition when necessary the problem should be addressed | 23:56 |
| TheJulia | anyway, I've got a patch, I'm going to work on and push up shortly. Steve is likely going to work on something like a "make this 4k" | 23:56 |
| TheJulia | kind of, yeah, but it has to be done upfront | 23:56 |
| TheJulia | Anyway, I need to make some coffee or something and push a patch up shortly | 23:56 |
| clarkb | right you have to know if you're making an image for 512 or 4096 block sizes | 23:57 |
| clarkb | TheJulia: will a 512 byte block system figure out if the gpt partition is at byte 4097 intead? | 23:58 |
| TheJulia | so that is where it gets *more* fun | 23:59 |
| TheJulia | linux magically makes IO interactions for the user 512 | 23:59 |
| TheJulia | unless your working on a device which has it locked to 4096, like a loopback | 23:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!