Karel Zak wrote: > On Mon, Mar 08, 2010 at 10:18:27AM -0500, Martin K. Petersen wrote: ... >> It'd be great if you guys could share what you have been doing to the >> tooling. > > small summary: > > - libblkid provides unified API to topology information, it supports: > - ioctls (kernel >= 2.6.32) > - sysfs (kernel >= 2.6.31) > - stripe chunk size and stripe width for DM, MD. LVM and evms on > old kernels > - libparted and fdisk are linked against libblkid > > - fdisk supports 4KiB logical sector size (util-linux-ng >= 2.15 > - fdisk supports 4KiB physical sector size (util-linux-ng >= 2.17) > - fdisk uses 1MiB alignment (or more if optimal I/O size is bigger) > and alignment_offset for all partitions in non-DOS mode > (util-linux-ng >= 2.17.1) > > - parted supports 4KiB physical sector size > - parted uses 1MiB alignment for disks with unknown topology, disks > with topology information are aligned to optimal (or minimum) I/O > size (parted >= 2.1) > > - EFI GPT code in the kernel has been updated to works properly with > 4KiB sectors (kernel >= 2.6.33) > > - mkfs.{ext,xfs,gfs2,ocfs2} have been update to work properly with > topology information, mkfs.{ext,xfs} are linked against libblkid > for compatibility with old kernel (for stripe chunk size / width) > > - Fedora-13/RHEL6 installer uses libparted with 4KiB support > > - alignment_offset & 4KiB support is planned for LUKS (cryptsetup) Thanks for the summary, Karel. In case anyone wants more high-level detail on the parted front, here's its NEWS file: http://git.debian.org/?p=parted/parted.git;a=blob;f=NEWS Currently, I'm not planning much for Parted, other than clean-up. For example, I want to remove all of the FS-related code (it's horribly bit-rotted) from the package, with the exception of HFS/HFS+ and FAT resizing capabilities, since AFAIK, Parted has the only free implementations. If any of you know of other implementations or work in progress, please let me know. Related information, prompted by my recent encounter with a tool that refused to let me use a GPT partition table. Partition table formats: prefer GUID/GPT: Having spent more than my share of time looking at partition table formats recently, I am now strongly biased against DOS partition tables, and for GUID/GPT ones. In addition to allowing for >2GiB partition offsets and lengths, GPT tables provide for better protection in case of corruption (checksums, backup table at end of disk) and don't have the anachronistic distinction of primary and extended/logical partitions (all partitions are "primary"). You can even give each partition a name. The only reason to use a DOS partition table on a new installation is if you're stuck with a requirement of using an OS like XP on bare metal. Please consider encouraging the use of GPT partition tables... or at least do not *dis*courage their use. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html