Daniel J Blueman wrote: > On Mon, Feb 23, 2009 at 11:06 PM, Curtis Gedak <[email protected]> wrote: > >> Daniel J Blueman wrote: >> >>> On Sun, Feb 22, 2009 at 5:01 PM, Curtis Gedak <[email protected]> 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 <[email protected]> >>> >>> >> 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. > > I hadn't thought about a spin button. That would certainly open up more possibilities without complicating the user interface too much. >> 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 >
_______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
