RE: LBA48 partitioning scheme

>> It's my understanding that the xbox-linux kernel currently detects
the 
>> fatx 'F' and 'G' partitions if present (as hda55 and hda56 
>> respectively). This is achieved by having the starting sectors
hardcoded 
>> into the Xbox partition detection code.

If that's true (I don't know), then there must be assumptions about
where 'F:' ends and 'G:' starts (since it can vary - even without my
partition table).

I'm guessing that Xbox-Linux doesn't have specific support for F:/G:.
Instead, it probably has support for a partition that's everything after
the standard Xbox partitions (C:-E:), meaning it starts at offset 8GB
into the drive, and goes to the end of the drive (assuming < 128GB
drive).  That happens to correspond to F: (in certain FATX layouts), but
doesn't necessarily mean direct support/knowledge of FATX F:

I also seem to remember a special partition in Xbox-Linux (maybe hda56)
that used Linux's LBA48 (before my Xbox Kernel LBA48 patches) to access
all the space after 128GB.  This happens to correspond to G: in the MS
Xbox kernel with LBA48 support.

But, F: and G: only *default* to those regions - they can be changed
(even without partition table mods).  A user can (with LBA48 patches,
without using partition table) say that F: takes up the entire rest of
the drive (no G: at all).  G: was added for backward compatibility with
Pre-LBA48 Xbox kernels.

Of course, by using the parition table, ANY/ALL Xbox partitions
(including C:-E:) can be moved to any place on the drive.  I think
people are only moving/resizing F:/G:, though.

>> What happens currently if someone using Paul's partitioning scheme 
>> defines a fatx partition which starts at the same sector as either
'F' 
>> or 'G' would but ends at a different location? Will Linux still
detect 
>> it as hda55/hda56 but with the wrong size? If it does will this
result 
>> in data corruption upon writing to the partition, or are there checks
to 
>> stop this?

As I said above, any partition table changes made on the Xbox-Kernel
side, OR choosing to use the entire remainder of the drive (including >
128GB space) for F: would cause problems with Xbox-Linux (since
Xbox-Linux only has hard-coded tables for its partitions - mimicing the
original Xbox C:-E: hard-coded partition layout, plus the hda55/hda56
partitions added by Xbox-Linux).

Unless I'm wrong about this, then you'll definitely get data corruption
on one side or the other by (for example) writing to the middle of a
FATX partition from Linux (because of a mismatch in parition layouts),
or vice-versa.

>> If the combination of a xbox-linux kernel supporting only hardcoded F

>> and G partitions + usage of Paul's partitioning scheme results in
data 
>> loss then surely there is a good case for making the kernel aware of
the 
>> Paul's partitioning scheme in some way.

It seems to me that it's more "user friendly" for Xbox-Linux to support
running in as many situations as are known to be out there.  We know
lots of people are using LBA48 for > 128GB drive support on the
Xbox-kernel side (whether/not it's considered to be "standard": it's
"out there" and "real"), and may either use partition tables or have
chosen to use F: for all space after E:.  Why not let those users try
Xbox-Linux without trashing their hard drives?

Adding support to Xbox-Linux for the *optional* partition table used by
my LBA48 patches seems like it would be easy, and would have NO effect
if you don't have a partition table on the drive.  I don't see any
reason to risk corrupting user's hard drives - other than
'philosophical' reasons.

I haven't done any Xbox development for many months.  I don't use
Xbox-Linux.  So, it doesn't really affect me either way.  I'm just
stating my opinion - feel free to ignore it.

Regards,

- Paulb



-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Richard Osborne
Sent: Thursday, June 02, 2005 10:57 PM
To: [email protected]
Subject: Re: [Xbox-linux] LBA48 partitioning scheme


It's my understanding that the xbox-linux kernel currently detects the 
fatx 'F' and 'G' partitions if present (as hda55 and hda56 
respectively). This is achieved by having the starting sectors hardcoded

into the Xbox partition detection code.

What happens currently if someone using Paul's partitioning scheme 
defines a fatx partition which starts at the same sector as either 'F' 
or 'G' would but ends at a different location? Will Linux still detect 
it as hda55/hda56 but with the wrong size? If it does will this result 
in data corruption upon writing to the partition, or are there checks to

stop this?

If the combination of a xbox-linux kernel supporting only hardcoded F 
and G partitions + usage of Paul's partitioning scheme results in data 
loss then surely there is a good case for making the kernel aware of the

Paul's partitioning scheme in some way.

However if there are already checks to prevent this situation from 
occouring please ignore everything I just said.

David Pye wrote:

>
>
>I don't intend to come across as hostile in a personal sense, so please

>don't
>interpret my response as such.
>
>Personally, my feelings are that xbox-linux should not go out of its 
>way to
>support 'illegal' stuff on the xbox - and a partition table designed
for use 
>with an illegal bios, and ONLY with an illegal bios (e.g. evox, xecuter

>bioses) falls into that category.
>
>I suspect that most of the team probably feel this way, although I 
>don't
>pretend to speak for them.  
>
>We have made an effort to support things that fall into one of two 
>categories:
>
>a)  Things that interoperate with the legal, and pre-existing MS 
>applications
>- fatx, and MS partition support, basically.
>
>b)  Things that are linux-native.
>
>Supporting this partition table 'standard', which is basically the 
>de-facto
>standard for illegal bioses, and is used by nothing else, falls into
neither 
>of those categories.
>
>While this of course doesn't restrict your freedom in posting your 
>patches to
>this list, I think it is something that we (we being the developers
with CVS 
>commit access ;) ) should consider, and decide whether to alter the
above 
>outlined policy.    My personal feeling is that we shouldn't, but I
would be 
>keen to hear, and obviously respect the feelings of the majority.
>
>Also, from a technical sense, I dislike another type of partition table

>layout, especially with such a narrow area of usefulness.   The
existing xbox 
>hardcoded partition offsets are bad enough, without another quirky 
>system
>which is xbox-only.  
>
>David
>
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Xbox-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/xbox-linux-devel




-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005