On Wed, May 30, 2001 at 01:28:31PM +0200, Christoph Ewering wrote: > > I can not understand what´s so difficult to put information about the > filesystem in the partition-table?
the partition table is the wrong place for such data, its stupid how overloaded some disklabels *cough apple's *cough* have become with so much irrelevant and extraneous data. > So i can mark partitions as ext2fs-big or ext2fs-little and the kernel > supports both methods or by a recompile only one of both methods. So > every architecture can read with maximum performance from the filesystem. well it is certainly possible to maintain two versions of every filesystem driver and use a mount option to switch between them, but its more code to maintain an in general just more trouble i imagine. i tend to think the least complication in filesystem drivers is best especially given how much trouble at least linux kernel people seem to have keeping the fs corruption bugs away. (the 2.2 series didn't stop eating filesystems until 2.2.14, we won't talk about 2.4). > I think it is absolutly stupid that x86 rules. They are slower than > Alphas, use more power than PPCs. yeah well life sucks, deal with it. > A lot of work at the big-endian front has to be done again, because a > lot of software is or was not endianess-clean, (examples are XMMS, > FireWire-Driver, some other Hardware-Drivers, etc.) this is a whole other issue, sloppy coding, and endianness isn't the only bugger here either, just look at all the stupid stuff comparing a char with EOF and running off wildly into endless loops on powerpc (and sparc too i think) as a result... > > If the system disk of my PPC box dies, I'll be happy to restore it from > > backup > > on some other machine... > > That´s no problem with the idea above. For restore speed is no need, so > it does not matter if i loose 1% filesystem performance for backups or > repairs. But i think if a linux-box runs low on memory, 1% faster > disk-I/O can make a lot of difference. maybe, it all depends how much work it is to either maintain a big and little endian filesystem driver or to make some mount time option to twiddle it. that of course still won't help you (performance wise) if you move a disk from one endianess to another permanently. unless you run some most likely rarely used, bitrotted, buggy converter. (yes the ext2fs one was pretty sucessful, but i did have someone tell me it ate a filesystem or two...) its all tradeoffs and what the best ones are to make. in this case i suspect code simplicity and maintainability is going to win out. -- Ethan Benson http://www.alaska.net/~erbenson/
pgpzFWAbYYq7I.pgp
Description: PGP signature
