Description of problem: If I use "fdisk -b 4096" to use a sector size of 4096 instead of 512, fdisk contradicts itself. I noticed the following issues: 1) fdisk says that the kernel reported a smaller physical sector size than the logical one. This seems to be, because it does not distinguish whether the logical sector size is passed on the commandline or reported by the kernel. 2) fdisk says that it uses as a unit sectors with the size of the given sector size, but the start and probably also the end sector used as input and displayed using "p" are still using 512 byte sector size 3) Using -b "4096" makes fdisk allow the first sector of a new partition to be 256 instead of 2048, but then the sector 256 using a sector size of 512 is used. Also why does this arbitray restriction exist at all? AFAIK sector 1 could be the first sector of the first partition without any restrictions wrt. linux. But the restriction on sector 2048 seems not to make any sense. Version-Release number of selected component (if applicable): 2.17.1-5.fc13 How reproducible: always Steps to Reproduce: 1. Use fdisk -b 4096 -u -c ... Actual results: Inconsistency as described above. Expected results: Consistent output. Additional info: fdisk on F12 seems not to restrict the first sector if dos compat mode is disabled.
(In reply to comment #0) > Description of problem: > If I use "fdisk -b 4096" to use a sector size of 4096 instead of 512, fdisk > contradicts itself. > > I noticed the following issues: > 1) fdisk says that the kernel reported a smaller physical sector size than the > logical one. Ah.. the current "-b <size>" behaviour is broken at all. Good catch. The fdisk command differentiate between logical and physical sector size since 2.17. Unfortunately, the -b option changes the logical sector size only. I'll fix it for the next release 2.17.2. > 2) fdisk says that it uses as a unit sectors with the size of the given sector > size, but the start and probably also the end sector used as input and > displayed using "p" are still using 512 byte sector size The "p" uses logical sector size, so 4096 in your example. > 3) Using -b "4096" makes fdisk allow the first sector of a new partition to be > 256 instead of 2048, but then the sector 256 using a sector size of 512 is > used. Also why does this arbitray restriction exist at all? AFAIK sector 1 > could be the first sector of the first partition without any restrictions wrt. > linux. But the restriction on sector 2048 seems not to make any sense. It makes a lot of sense, we use 1MiB offset (=2048 512-byte sectors, or =256 4096-byte sectors) by default since 2.17. This default is the best for all possible scenarios (4K disks, raids, old disk, ...). It would be nice to have a way how change the begin of the first partition in the expert mode, it seems that the "b" expect command is too restricted now. I'll try to fix this for the next major release (util-linux-ng 2.18).
(In reply to comment #1) > (In reply to comment #0) > The fdisk command differentiate between logical and physical sector size since > 2.17. Unfortunately, the -b option changes the logical sector size only. I'll > fix it for the next release 2.17.2. > > > 2) fdisk says that it uses as a unit sectors with the size of the given sector > > size, but the start and probably also the end sector used as input and > > displayed using "p" are still using 512 byte sector size > > The "p" uses logical sector size, so 4096 in your example. Iirc it uses logical sector size only for the amount of blocks. Start and end probably still use physical sector size because they use 512 byte sized sectors even with -b 4096. Btw. maybe the output could also say "Sectors" instead of "Blocks", e.g.: Device Boot Start End Sectors Id System /dev/sdb1 1 3907029167 1953514583+ ee GPT > > 3) Using -b "4096" makes fdisk allow the first sector of a new partition to be > > 256 instead of 2048, but then the sector 256 using a sector size of 512 is > > used. Also why does this arbitray restriction exist at all? AFAIK sector 1 > > could be the first sector of the first partition without any restrictions wrt. > > linux. But the restriction on sector 2048 seems not to make any sense. > > It makes a lot of sense, we use 1MiB offset (=2048 512-byte sectors, or =256 > 4096-byte sectors) by default since 2.17. This default is the best for all > possible scenarios (4K disks, raids, old disk, ...). Is there some overview / explanation how this is better than e.g. 20480 bytes? This is what gdisk for GPT uses by default for the first partition with an 4096 byte alignment. The only source for the 1MiB alignment I found is compatibility with windows.
(In reply to comment #2) > > It makes a lot of sense, we use 1MiB offset (=2048 512-byte sectors, or =256 > > 4096-byte sectors) by default since 2.17. This default is the best for all > > possible scenarios (4K disks, raids, old disk, ...). > > Is there some overview / explanation how this is better than e.g. 20480 bytes? > This is what gdisk for GPT uses by default for the first partition with an 4096 > byte alignment. The only source for the 1MiB alignment I found is compatibility > with windows. The 1MiB is usable for: - classic disks with 512-byte sectors - new 4096-byte sector disks - new 4096-byte sector disks that does not properly report disk topology (e.g. some new WD disks report 512-byte sectors, but internally use 4K...) - new disks + old kernel (< 2.6.31) where the system does not have a clue about disk topology - desktop class 4096-byte sector disks (disks with alignment compensation for backward compatibility with traditional DOS "63-sectors" partitioning) The most complete docs about this topic you can found at: https://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues http://people.redhat.com/msnitzer/docs/io-limits.txt
(In reply to comment #3) > (In reply to comment #2) > > > > It makes a lot of sense, we use 1MiB offset (=2048 512-byte sectors, or =256 > > > 4096-byte sectors) by default since 2.17. This default is the best for all > > > possible scenarios (4K disks, raids, old disk, ...). > > > > Is there some overview / explanation how this is better than e.g. 20480 bytes? > > This is what gdisk for GPT uses by default for the first partition with an 4096 > > byte alignment. The only source for the 1MiB alignment I found is compatibility > > with windows. > > The 1MiB is usable for: > - classic disks with 512-byte sectors > - new 4096-byte sector disks > - new 4096-byte sector disks that does not properly report disk topology (e.g. > some new WD disks report 512-byte sectors, but internally use 4K...) > - new disks + old kernel (< 2.6.31) where the system does not have a clue about > disk topology But a 20480 byte offset will afaics also work for all these cases. > - desktop class 4096-byte sector disks (disks with alignment compensation for > backward compatibility with traditional DOS "63-sectors" partitioning) In case of alignment compensation, i.e. physical sector 1 becomes logical sector 0, then both offsets will fail, i.e. not align the partition to the physical sectors. > The most complete docs about this topic you can found at: > https://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues > http://people.redhat.com/msnitzer/docs/io-limits.txt It only says that the 1 MiB alignment is used, but there is no justification why it is better than any othter n*4096 byte alignment.
(In reply to comment #4) > > The 1MiB is usable for: > > - classic disks with 512-byte sectors > > - new 4096-byte sector disks > > - new 4096-byte sector disks that does not properly report disk topology (e.g. > > some new WD disks report 512-byte sectors, but internally use 4K...) > > - new disks + old kernel (< 2.6.31) where the system does not have a clue about > > disk topology > > But a 20480 byte offset will afaics also work for all these cases. I forgot very important thing. 1MiB offset is good for alignment to the usual optimal_io_size (32K, 64K, ...). The 20480 byte offset is too small. Note that we use 1MiB as a grain for all partitions, it's not only offset for the first partition. > > - desktop class 4096-byte sector disks (disks with alignment compensation for > > backward compatibility with traditional DOS "63-sectors" partitioning) > > In case of alignment compensation, i.e. physical sector 1 becomes logical > sector 0, then both offsets will fail, i.e. not align the partition to the > physical sectors. Yes, this my point should be excluded from the list. Sorry.
(In reply to comment #1) > Ah.. the current "-b <size>" behaviour is broken at all. Good catch. > > The fdisk command differentiate between logical and physical sector size since > 2.17. Unfortunately, the -b option changes the logical sector size only. I'll > fix it for the next release 2.17.2. The problem should be fixed in upstream code as well as in Fedora >= 12. Closing.