FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 03-21-2012, 01:32 PM
John Reiser
 
Default Free space after partitioning

> parted.Geometry instance --
> start: 63 end: 2047 length: 1985
> -> the first sector is MBR. Why there are additional 62 sectors skipped
> before the first free region? Is it because of alignment rules?

It's because of traditional BIOS+DOS rules. The entire first track
is expected not to be used by any partition. Because there are 63 sectors
per track, then the first partition starts at sector 63. During the first
10 or 15 years of consumer-priced harddrives, this made sense because
the sectors/track was a direct consequence of disk geometry, and having
the entire first logical track of a partition aligned on to a physical
track of the device allowed for speeding up common filesystem operations.
For about the last 10 or 15 years, ever since harddrives had their own
embedded programmable [but not by users] controller, the reported number
of sectors/track is mostly fictitious, and is constrained by the bit widths
of ancient data layouts, and has almost nothing to do with actual sectors/track,
which often varies depending on "zones" (position of the arm with heads.)

Today the sectors/track actually does matter for USB flash memory, which
often has an effective track size of 128KiB [known as an "erase block"],
and where read+modify+write really does take several times as long as a
plain write of the entire 128KiB. The embedded controller on the flash
drive _knows_ how FAT32 works, and is optimized heavily so that the usual
FileAllocationTable is placed optimally with respect to 128KiB blocks.
In particular, the embedded controller often caches (in on-chip SRAM)
the 128KiB block which corresponds to the FAT, and this block often is assumed
to be 4MiB into the filesystem. If your filesystem does not take advantage
of this, or if you re-partition the drive with different parameters,
then performance may suffer significantly.

--

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 03-21-2012, 05:12 PM
Chris Murphy
 
Default Free space after partitioning

On Mar 21, 2012, at 8:12 AM, David Lehman wrote:
> On Wed, 2012-03-21 at 14:32 +0100, Jan Safranek wrote:

>> What alignment is used then? Why the partitions don't follow each other?
>
> The kernel has specified that partitions on that disk should always
> start on a 2048-sector boundary. Aligning up from sector 1 or 63 gets
> you to sector 2048. Likewise, the rest of the start sectors will all be
> multiples of 2048.

This is why it's better to define partition sizes in MB (really MiB) rather than sectors, bytes or KB. Then the starts will butt up against the previous ends.

Chris Murphy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 03-23-2012, 10:44 AM
Jan Safranek
 
Default Free space after partitioning

On 03/21/2012 02:18 PM, David Lehman wrote:
>> start: 63551 end: 64259 length: 709
>> > This free region is at the beginning of the extended partition. The
>> > extended partition starts at sector 63488 and the first logical
>> > partition starts at 67584.
>> > -> Why there is a free space at all? I did not request any.
>> > -> What are 3325 sectors between the free space end and the first
>> > logical partition start? I know, there is one sector for logical
>> > partition metadata, but 1.6MB, which is not part of any partition nor
>> > free space region, seems too much to me.
>> > -> Similarly, what are 63 sectors between the extended partition start
>> > and the free space start? 1 sector is for logical partition metadata,
>> > but the rest?
>
> We are somewhat more liberal with rounding start sector up for logical
> partitions, basically because parted is more aggressive in aligning
> start of logical partitions than it is with normal partitions. Also, we
> need to account for at least one sector of metadata before each logical
> partition. In some unfortunate cases this bump to the next MB boundary
> can amount to 2047 520-byte sectors. Again, parted is so aggressive with
> this that we had to do the same in order to ensure that parted
> magic/fixups do not cause unwanted surprises when the partitions are
> added to disk.
>

Ok, I understand the free space *between* logical partitions. But the
above is the first logical partition. Looking at the raw partition data
(obtained by cfdisk), I can see that the first logical partition
metadata are at sector 63488, i.e. the first sector of the extended
partition. The real partition data starts at sector 67584, which is 2
megabytes (!) after the metadata. I would expect just 1 megabyte
between, for the alignment. But that's something I can live with.

What troubles me much more is that
pyanaconda.storage.partitioning.getFreeRegions() reports a free region
in these 2 megabytes between logical partition metadata and real
partition data! IMHO nothing should be allowed there!

fdisk output:
/dev/sdb1 2048 22527 10240 83 Linux
/dev/sdb2 22528 43007 10240 83 Linux
/dev/sdb3 43008 63487 10240 83 Linux
/dev/sdb4 63488 2097151 1016832 5 Extended
/dev/sdb5 67584 88063 10240 83 Linux
...

cfdisk output:
# Type Sector Sector Offset Length ...
1 Primary 2048* 22527* 0 20480*
2 Primary 22528* 43007* 0 20480*
3 Primary 43008* 63487* 0 20480*
4 Primary 63488* 2097151* 0 2033664*Extended
5 Logical 63488* 88063* 4096# 24576
6 Logical 88064* 110591* 2048# 22528
...
Offset is the distance between metadata and partition data - fdisk shows
only the real partition data, usable by /dev/sda5 block device.

Jan

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 03-23-2012, 12:30 PM
David Lehman
 
Default Free space after partitioning

On Fri, 2012-03-23 at 12:44 +0100, Jan Safranek wrote:
> On 03/21/2012 02:18 PM, David Lehman wrote:
> >> start: 63551 end: 64259 length: 709
> >> > This free region is at the beginning of the extended partition. The
> >> > extended partition starts at sector 63488 and the first logical
> >> > partition starts at 67584.
> >> > -> Why there is a free space at all? I did not request any.
> >> > -> What are 3325 sectors between the free space end and the first
> >> > logical partition start? I know, there is one sector for logical
> >> > partition metadata, but 1.6MB, which is not part of any partition nor
> >> > free space region, seems too much to me.
> >> > -> Similarly, what are 63 sectors between the extended partition start
> >> > and the free space start? 1 sector is for logical partition metadata,
> >> > but the rest?
> >
> > We are somewhat more liberal with rounding start sector up for logical
> > partitions, basically because parted is more aggressive in aligning
> > start of logical partitions than it is with normal partitions. Also, we
> > need to account for at least one sector of metadata before each logical
> > partition. In some unfortunate cases this bump to the next MB boundary
> > can amount to 2047 520-byte sectors. Again, parted is so aggressive with
> > this that we had to do the same in order to ensure that parted
> > magic/fixups do not cause unwanted surprises when the partitions are
> > added to disk.
> >
>
> Ok, I understand the free space *between* logical partitions. But the
> above is the first logical partition. Looking at the raw partition data
> (obtained by cfdisk), I can see that the first logical partition
> metadata are at sector 63488, i.e. the first sector of the extended
> partition. The real partition data starts at sector 67584, which is 2
> megabytes (!) after the metadata. I would expect just 1 megabyte
> between, for the alignment. But that's something I can live with.
>
> What troubles me much more is that
> pyanaconda.storage.partitioning.getFreeRegions() reports a free region
> in these 2 megabytes between logical partition metadata and real
> partition data! IMHO nothing should be allowed there!

getFreeRegions does not claim that you are allowed to create partitions
within every free region it reports.


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 03-23-2012, 01:21 PM
Jan Safranek
 
Default Free space after partitioning

On 03/23/2012 02:30 PM, David Lehman wrote:
> getFreeRegions does not claim that you are allowed to create partitions
> within every free region it reports.

Ok, let me formulate my question in another way. How does a
pyanaconda.storage (or pyparted) user find all the space occupied by a
logical partition, incl. it's metadata sector?

I thought I could compute it using end of previous free region (if any)
or end of previous partition, but that's broken.

Jan

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 03-23-2012, 01:43 PM
Matt Rose
 
Default Free space after partitioning

On 03/23/2012 10:21 AM, Jan Safranek wrote:

On 03/23/2012 02:30 PM, David Lehman wrote:

getFreeRegions does not claim that you are allowed to create partitions
within every free region it reports.

Ok, let me formulate my question in another way. How does a
pyanaconda.storage (or pyparted) user find all the space occupied by a
logical partition, incl. it's metadata sector?

I thought I could compute it using end of previous free region (if any)
or end of previous partition, but that's broken.

Jan

"Does not do what you think it does" != Broken

Matt

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 03-23-2012, 01:51 PM
Jan Safranek
 
Default Free space after partitioning

On 03/23/2012 03:43 PM, Matt Rose wrote:
> On 03/23/2012 10:21 AM, Jan Safranek wrote:
>> On 03/23/2012 02:30 PM, David Lehman wrote:
>>> getFreeRegions does not claim that you are allowed to create partitions
>>> within every free region it reports.
>> Ok, let me formulate my question in another way. How does a
>> pyanaconda.storage (or pyparted) user find all the space occupied by a
>> logical partition, incl. it's metadata sector?
>>
>> I thought I could compute it using end of previous free region (if any)
>> or end of previous partition, but that's broken.
>>
>> Jan
> "Does not do what you think it does" != Broken

I meant my assumption is broken .

Anyway, with help of David Lehman, parted.Disk.getFirstPartition() is
what I need. I can walk the partitions then using nextPartition() and
watching its type I can get what I want - metadata location, free space
and partition data itself.


Jan

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 11:44 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org