Rupert Pigott wrote:
On Mon, 26 Feb 2007 14:37:15 -0800, Matthew Dillon wrote:The alternative is to set a specific endianess for the filesystem in stone, just like the 'network byte order' concept locked in a particular byte ordering for packets. People today STILL hate the fact that they have to translate certain protocols to network byte order even when the machines on both ends use the same byte order, but one that happens to not be 'network' byte order.That doesn't seem like a good enough reason to add more conditional branches to the critical paths, make the wire protocol more complicated and make it more difficult for the Mk.I eyeball to parse the dumps. It also pushes an additional conditional into at runtime. A fixed-endian filesystem makes that conditional "free" and therefore reduces the performance hit - and makes the life of the compiler trivial.
It's one branch at load and one branch at store for meta-data. The endian is not likely to change once the filesytem is mounted; therefore, in the critical path the processor's branch prediction should almost always predict the correct path taken or not taken.
Besides, the meta data is most likely to already be in memory, and thus you're down to just the branch on store.
If it really is an issue, you can always do per filesystem function pointers to either a nop function or the correct endian translation function. With today's processors which do not yet include good indirect branch support (i.e. pointer based function calls), this would make the best case always as slow as a branch prediction which "always misses". This will of course likely improve with the next generation of processors, such as AMD's K8L which include indirect branch prediction.
Changes between system endians will likely be very rare anyways. Best case is there would be an "endian field" in the meta-data which is always set to little-endian. Implementations which do not support endian changes would simply always fail to mount.
A seperate tool may be made which does endian conversion on media before mounting on a different endian system. Then, the compiler would always optimize the kernel filesytem code to only support the endian of the computer it is compiled for.
We could also do a per segment conversion of meta-data at run time as the segment is accessed, but the need for conversion will likely be rare anyways. Such conversions may require additional moving of data to other "already converted segments" since we would likely not want to overwrite existing meta-data to insure transactional safety. A background thread could also do the conversion as necessary starting with "unused" segments, and do "performance optimization" at the same time.
As far as I know, there is no good reason today for a microprossor designer to choose one endian over another from a design standpoint. Today, it more or less comes down to preference. Therefore, it is highly unlikely to see another processor architecture which is not big-endian or little-endian.
As for network protocols, I prefer negotiating the endian such that the endian of the "server" or "peer under higher load" gets preference. Then, the "client" or "peer under lower load" takes on the burden of conversion. Then developer only has to worry about endian changes to interface with the network API. For most developers, this means that communication will almost always take place in little-endian between x86 machines.
As far a human readable binary, that's why we should build tools to format the data. =)
- Jason
