Re: LBA48 partitioning scheme
"gary ng" <[email protected]> Sat, 4 Jun 2005 12:23:39 +0800
| Newsgroups | gmane.linux.ports.xbox.devel |
|---|---|
| Message-ID | <[email protected]> |
I already have written the patch for 2.4 kernel long ago but as far as I know it was being rejected :-) However, I no long see the need of it as I only do sofmodding and the two most popular HD upgrade programs are based on linux and would automatically formatted the HD into the 8-137 as F, beyond as G layout. So the net result is that most big HD out there follow this scheme, no need for your generic partition table at all :-) "Paul Bartholomew" <[email protected]> wrote in message news:000701c567f8$be991160$d500a8c0@paulxp... > >> 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 ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20