DragonFly kernel List (threaded) for 2007-02
Re: Initial filesystem design synopsis.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Trace: 1172555054 crater_reader.dragonflybsd.org 833 188.8.131.52
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:10697
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
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
As far a human readable binary, that's why we should build tools to
format the data. =)