Partition check order in fs/partition/check.c?

Partition check order in fs/partition/check.c?

[Peter Oberparleiter]

Hi,

I've got a few questions regarding partition checks in fs/partition/*.c of 
both Linux 2.4 and 2.5:

I ran into a situation in which an MSDOS partition table was incorrectly 
interpreted as an ACORN POWERTEC partition table, resulting in no valid 
partition being found. When I looked at fs/partition/acorn.c I noticed that 
the powertec partition check is kept fairly generic (adding bytes 1..511 of 
the MBR plus an offset and comparing the result with byte 512). In addition 
to this, the acorn-specific set of partition checks comes first in the list 
in fs/partition/check.c so that statistically, every one in 256 MSDOS 
partition tables (they got a fixed pattern at bytes 511 and 512) would be 
incorrectly identified as POWERTEC.

Now for the actual questions: what is the reason for the order of partition 
checks as it is? Couldn't the acorn tests be moved further down in the list 
to solve this particular problem? Also, is there a way to make the acorn test 
more specific?

A workaround for this problem would of course be to deselect the 
CONFIG_ACORN_PARTITION_POWERTEC option, but that wouldn't work in cases both 
acorn and msdos partition tables are used.

Thanks in advance for any kind of insight into this matter.


Regards,
  Peter Oberparleiter

Re: Partition check order in fs/partition/check.c?

[Russell King]

On Tue, Apr 01, 2003 at 11:33:03AM +0200, Peter Oberparleiter wrote:
> Now for the actual questions: what is the reason for the order of partition 
> checks as it is?

It's all to do with getting the right detection of the partitioning
scheme.  If the order is wrong, you either can't detect a scheme, or
you mis-detect a scheme every time.

> Couldn't the acorn tests be moved further down in the list to solve
> this particular problem?

Unfortunately not (on both counts.)

There are several partitioning schemes for Acorn drives (thanks to Acorn
never defining a decent partitioning method, vendors went off and each
did their own thing.)  So, we have the following schemes:

	Scheme			512-byte sector offset
1.	ICS			0
2.	PowerTec		0
3.	EESOX			7
4.	Cumana			3
5.	ADFS			3

Schemes 1 through 3 may (or may not) contain valid ADFS information at
sector 3.  Scheme 4 definitely has valid ADFS information at sector 3.
Therefore, to correctly identify all in this list, ADFS must come last
in this list.

However, there are a large percentage of drives which have an old x86
BIOS partition table at sector 0.  To prevent mis-detecting these
drives (which would render the ADFS partition check useless) the x86
BIOS partition check must come after ADFS.

So, there are three dependencies - ICS, PowerTec, EESOX before Cumana,
Cumana before ADFS, ADFS before x86 BIOS.  This means PowerTec must
come before x86 BIOS.

> Also, is there a way to make the acorn test more specific?

s/acorn/powertec/

We may be able to check that start,start+size lies within the overall
drive size.  Whether this solves the problem will depend upon the contents
of sector 0 for the x86 drives which clash.  However, as drive sizes
increase, this test will become less and less effective (and at 2TiB
it doesn't help at all.)

Another solution would be to pass a kernel parameter like
"partition=hda:msdos,hdb:adfs" to force specific partition interpretation.
However, this could cause issues with hotplug stuff.  Another alternative
is to just turn off the troublesome powertec scheme if you don't have any
drives using that scheme.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Partition check order in fs/partition/check.c?

[Peter Oberparleiter]

On Tuesday 01 April 2003 12:35, you wrote:
[info about acorn partitioning schemes]
Ok, thanks for the explanation about the scheme dependencies. I guess adding 
a comment like "/* this must come before msdos */" in the respective line of 
fs/partition/check.c could cut down in the number of people asking you the 
same question over and over again.. :-)

> > Also, is there a way to make the acorn test more specific?
>
> s/acorn/powertec/
>
> We may be able to check that start,start+size lies within the overall
> drive size.  Whether this solves the problem will depend upon the contents
> of sector 0 for the x86 drives which clash.  However, as drive sizes
> increase, this test will become less and less effective (and at 2TiB
> it doesn't help at all.
Hm, what do you think of these additional checks:

1. Check for overlap of partitions
2. Check for number of recognized partitions (i.e. size != 0) > 0 
3. Check for struct ptec_partition.unused1, unused2, unused5 == 0 (assuming 
they default to zero)

Anyway, thanks again for the info.


Regards,
  Peter Oberparleiter

Re: Partition check order in fs/partition/check.c?

[Russell King]

On Tue, Apr 01, 2003 at 03:14:56PM +0200, Peter Oberparleiter wrote:
> Hm, what do you think of these additional checks:
> 
> 1. Check for overlap of partitions

That's something which should be done for any partitioning method imho.
I have heard of some situations where, on x86 machines, the DOS and
ext2 filesystems overlapped, but somehow managed to keep working for
a considerable period of time.  Then when it all goes wrong, the user
blamed Linux for screwing their DOS/Windows partition.

This might be an acceptable way out of this problem.

> 2. Check for number of recognized partitions (i.e. size != 0) > 0 

If the checksum seems to be correct and you mis-parse an x86 bios
partition table as powertec, chances are that you'll have a non-zero
size word somewhere in that sector.

> 3. Check for struct ptec_partition.unused1, unused2, unused5 == 0
> (assuming they default to zero)

Unfortunately they don't default to zero.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Partition check order in fs/partition/check.c?

[jw schultz]

On Tue, Apr 01, 2003 at 03:14:56PM +0200, Peter Oberparleiter wrote:
> Hm, what do you think of these additional checks:
> 
> 1. Check for overlap of partitions

Be very careful here.  While you better not _use_ overlapping
partitions, a partition table with overlapping partitions is
a traditional UNIX default.  It is usually something like

	part	start	length
	a	0	3/8 drive
	b	3/8	1/8 drive
	c	0	whole drive
	d	0	1/3 drive
	e	1/3	1/3 drive
	f	2/3	1/3 drive
	g	1/3	2/3 drive
	h	1/2	1/2 drive

In this way admins wouldn't repartition, just use the default
partitions in suitable combinations.  This actually reduced
the likelihood of overlapping partitions because the
partitioning tools were sometimes confusing causing custom
partition to have 1 cylinder overlaps.  When drives got to be
larger than 2GB these default partition sizes became
increasingly pointless.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt