On Mon, Feb 23, 2009 at 11:06 PM, Curtis Gedak <ged...@gmail.com> wrote: > Daniel J Blueman wrote: >> >> On Sun, Feb 22, 2009 at 5:01 PM, Curtis Gedak <ged...@gmail.com> 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. >>> >> >> The attached and tested patch (against gparted 0.4.3) replaces the >> 'Round to cylinders' checkbox with 'Round to megabytes' (the 1990s is >> finally over), though it doesn't indicate why one may select it. Let >> me know if 'Performance (megabyte) alignment' or such is preferred. >> >> I have corrected the incorrect rounding logic, which was passing >> potentially overlapping partition data to libparted. However, all is >> not done since libparted's default constraints defeat the alignment, >> but it does what is needed for the GParted component; I'll look at >> getting a patch together for libparted. The translations need >> updating, but this is clear with the updated English strings. >> >> Thanks, >> Daniel >> >> commit info: >> >> Replace option to perform cylinder-alignment by megabyte-alignment, >> useful for avoiding performance and longevity loss on storage arrays >> and SSD disks. >> Signed-off-by: Daniel J Blueman <daniel.blue...@gmail.com> >> > > Thank you Daniel for the effort you took to create a patch for GParted. I > can tell that this is an important issue to you, and I agree that it is one > that should be addressed. > > Following are my comments with regards to the patch. > > These comments are not all parted-devel specific items, but may be useful > for others reading this thread. If desired by the parted developers, we can > open a new bug for GParted and continue the discussion there.
> COMMENTS: > > 1) I think it is important to continue to support the older C/H/S rounding. > It might not be as applicable with today's hard drives, but I strongly > believe in maintaining backward compatibility as much as is possible. > > To implement such support, I think the GParted GUI would need radio buttons > to permit the user to choose either "Round to cylinders" or "Round to > megabytes". Another radio button might be required for "strict sector > values" because GParted currently implements these. I was weighing up changing the radio button to a spin button for other alignments, but then we could equally allow eg 128KB alignment, thus the UI complexity and user decisions paths complicate, which is good to avoid. I also agree with your point though. > Default values for the radio buttons could be determined as follows: > > If no partitions exist on the device then > default to use round-to-megabytes > Else if the first partition uses cylinder boundaries then > default to use round-to-cylinders > Else > default to use round-to-megabytes > > NOTE: If the megabyte partition boundary logic is to be built into > libparted, then it might be better to enhance GParted to use this new > libparted logic. That way there would be less chance of differing results > between any GParted logic, and the libparted logic. :-) I do think it makes sense having it in libparted, however it's clear alignment is implemented and conflicts in both gparted and libparted. > 2) As a general rule with GParted, I leave the updating of all language > translations to the GNOME Translation Teams. If the *.po file updates were > committed, then the translation tracking would falsely represent that the > string "Round to megabytes" had been properly translated in each language. > See the following link: > http://l10n.gnome.org/module/gparted/ Good tip and thanks for the feedback, Daniel -- Daniel J Blueman _______________________________________________ parted-devel mailing list parted-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/parted-devel