Jim Meyering wrote: >>> I can already create partitions aligned to 128KiB boundaries. >>> This creates a first partition of just less than 1GiB, >>> and the second taking up the remainder of the space >>> and also using a size that's a multiple of 128KiB: >>> >>> dev=file; : > $file >>> k=1024 m=$(($k*$k)) g=$(($k*$k*$k)) >>> dd if=/dev/null of=$dev bs=1 seek=32GiB >>> parted -s $dev mklabel gpt >>> parted -s $dev u B mkpart primary $((128*$k)) $(($g-1)) >>> parted -s $dev u B mkpart primary $g $((32*$g - $m - 1)) >>> parted -s $dev u B p >>> >>> Model: (file) >>> Disk /t/file: 34359738368B >>> Sector size (logical/physical): 512B/512B >>> Partition Table: gpt >>> >>> Number Start End Size File system Name >>> Flags >>> 1 131072B 1073741823B 1073610752B primary >>> 2 1073741824B 34358689791B 33284947968B primary >>> >>> >>> Now, I think that this functionality >>> (snap-to-user-specified-or-system-derived-alignment) belongs in gparted, >>> and not in parted. >>> >> Yes, if we propose to add an option to say "tick, I know I have an >> SSD", but this adds more unnecessary user complexity, when the cost to >> non-SSDs is so low. >> >> What's (at worst) 128KB slack in partition layouts, when we already >> skip the first 63 sectors anyway? >> > > If that were the only cost, we'd switch right away. > However, parted's code is very fragile, and changing how it handles > constraints/alignment seems like it'd be very risky. Why go there > if it's not absolutely necessary? Besides, the functionality I think > you want (to make the process convenient or mandatory) belongs in a > higher-level tool. > > If the programmers and tools invoking parted cannot be bothered to > do a little modulo arithmetic and be aware of alignment, then they > shouldn't be choosing partition boundaries in the first place. > > Changing GParted to align to boundaries different that the old cylinder alignment scheme is definitely possible, and probably desirable. This would provide the alignment performance benefits to a large group of people, and still allow experts to use tools such as fdisk, or parted to hand craft their own partition boundaries.
Since Vista appears to be going to a 1MB boundary, it may be beneficial to adopt this as the new boundary standard. And since 1 MB is evenly divisible by 4kB and by 128kB, this should satisfy current and some potential future performance requirements. I believe this solution should work well on current hard drives, and solid state drives too. My assumption is that a 1MB boundary would be used for all partition tables, including MSDOS and GPT. Hence MSDOS would reserve 1MB at the start of the disk for the boot record, and GPT would do the same. MSDOS would also reserve 1MB at the front of each logical partition. For a disk that already contains a partition, my thought is that the default alignment algorithm should match the way the first partition is aligned. By this I mean if the first partition uses cylinder boundaries, then the default alignment for new partitions would be by cylinder alignment. If the first partition uses this new 1MB alignment, then new partitions would also use the 1MB alignment scheme. In the case of a disk containing no partitions, my thought is to default to using the 1MB partition alignment scheme, because modern disks often do not physically match the C/H/S reported (ie., xxx/255/63). Does the above 1MB alignment scheme sound logical, or have I missed something important? Regards, Curtis Gedak Maintainer of GParted _______________________________________________ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel
