[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Wheezy Installer Auto-Partition Oddity



On Sat, Jan 5, 2013 at 1:00 PM, Patrick Bartek <bartek047@yahoo.com> wrote:
>> From: Tom H <tomh0665@gmail.com>
>> Sent: Saturday, January 5, 2013 4:32 AM
>> On Fri, Jan 4, 2013 at 1:25 PM, Patrick Bartek <bartek047@yahoo.com>
>> wrote:
>>> From: Roger Leigh <rleigh@codelibre.net>
>>> Sent: Friday, January 4, 2013 3:02 AM
>>>>
>>>> LVM does not use unpartitioned space for anything TTBOMK. It uses
>>>> physical volumes (PVs) which are block devices (either partitions or
>>>> whole disks or RAID arrays etc.). These are entirely self-contained.
>>>> Internally, the PV contains its own metadata and extents which are
>>>> allocated to individual logical volumes within the volume group
>>>> containing the PV. It's simply impractical and fragile to use
>>>> unpartitioned space, and LVM only uses the devices (partitions) you
>>>> put the PVs on.
>>>
>>> That was what I read--somewhere?--in an article on LVM. It was just
>>> one sentence mentioned in passing and was never detailed.
>>>
>>> If using unpartitioned space is so "fragile" Why do the MBR or
>> GPT,
>>> etc. use it? Seems to be a great place to "hide" data about
>> something
>>> like a LVM partition that's not going to change frequently, and is
>>> beyond normal filesystem access. Just a thought.
>>
>> The MBR, whether on msdos or gpt, is a well-defined area at the
>> beginning of a disk, not a random space between partitions.
>>
>> There's no LVM data held off a PV, whether it's a partition or a disk.
>> The LVM metadata of a PV is stored in the second sector of that PV and
>> its LV "usable area" follows. Your article might have been referring
>> to this separation.
>
> So, again I ask: Why that 1MiB unpartitioned space before the beginning
> of a new partition? Both Debian 6 and 7 installer partitioner insert it
> (when you choose Auto-partition; don't know whether it does with Custom)
> as does gparted (Discovered that when I resized three existing contiguious
> primary partitions [no gaps added after resizing] and added two new
> logical partitions [gaps added automatically] on a 7 year old 512 byte
> sector 160GB drive). Got to be a reason. I don't think it's a bug.

I'm sorry, I only remember some things vaguely that's why I didn't
reply to your initial query but here goes.

fdisk upstream chose a 1MiB offset by default 2-3 years ago either for
compatibility with Windows or for compatibility with 4KiB-sector disks
(or both). For the latter, AFAIK, an offset of any multiple of 4KiB
would be good enough so I might be misremembering (on both counts!)...

As for the gaps between the partitions, *MAYBE* it's because the
installer passes a size (e.g. "200M") to the partitioner and, if that
size doesn't end at a 4KiB-multiple boundary, the next partition
starts at one.


Reply to: