On Sun, Feb 22, 2009 at 1:53 PM, Jim Meyering <[email protected]> wrote: > Daniel J Blueman wrote: > ... >>> But let's back up a step. >>> Do we really need to change anything? >>> Or are you proposing (like I think Eric was) a way to >>> make this merely more convenient? >> >> The question is: will the average user know and be prepared to do >> this? Probably not, so will experience a performance/longevity penalty >> which could have been avoided perhaps... > > I sincerely hope that the average user does not use parted ;-) > Even for those of us who have braved its murky depths, sometimes > it's hard to remember (or discover) how to do things the parted way. > >>> 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.
Yes, perhaps Matt Domsch's work is on the right lines, or no? http://www.mail-archive.com/[email protected]/msg02168.html > 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. Agreed; though it seems sensible to integrate as much of this into libparted and ensure the applications use the constraints, rather than duplicate the work in all the users of libparted: $ apt-cache rdepends libparted1.8-9 [trimming list] qtparted kvpm gnu-fdisk fatresize ubiquity parted gparted -- Daniel J Blueman _______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
