On Sun, 15 Apr 2007, Martin Rosenau wrote:
Hello.
Under Linux it is possible to mount both little-endian (x86) and
big-endian (sparc) Solaris UFS partitions. An endian-converting function
(similar to htonl) is used for this.
This feature should be available in Solaris, too, or a separate UFS
driver (ufs-otherendian) should be provided. This is very useful when
formatting removeable media using UFS and using them on both Sparc and
x86 machines.
Hi Martin,
this isn't exactly a new idea, of course :)
We've had a Solaris RFE for endian-independent UFS around a decade ago,
see (closed):
4054544 RFE: wish to support different endian byte order
You cannot see the "comments" section of that via bugs.opensolaris.org but
there's nothing in there that's so "secret" that it couldn't be shown
here, so I'm copying verbatim, to give you a hint where the nits are with
that idea:
[ comments section of RFE 4054544 ]
=========================================================================
I have done a little bit of prototyping of an endian independent ufs module.
While this would be a useful feature, fundamentally ufs is not designed as
an interchange format; it is a local file store that is specific to both
Solaris and the hardware it is running on.
Having said that, the issues with making ufs transferrable between Solaris
intel and Solaris sparc are these:
- Unlike ext2fs, pcfs, udfs, etc., a byte-order independent ufs will have to
support BOTH byte orders. In other words, ufs may be either big endian or
little endian, which means we may have to byte swap on either architecture.
The other file systems have a defined byte order, and swapping is only required
on the opposite byte order architectures.
- ufs file systems differ between intel and sparc in more than just byte
order. For instance, the fs_state and fs_npsect fields in the superblock
are swapped in little endian machines for increased compatibility with the
SVR4 ufs implementation. If byte swapping is enabled, then these two
fields need to be swapped as well.
- Perhaps the most difficult problem to solve is that even if you do have a
file system that understands both formats, you still can not yank a disk
off a sparc machine and plug it into the intel system and have it work.
The sd driver has intimate knowledge of the disk label and partition
information, which is totally incompatible between Solaris intel and
Solaris sparc.
- Byte swapping a file system is a very invasive procedure. My first attempt
at this problem was to intercept the points where metadata was read in or
written out, and perform the byte swap operation then. However the buffer
cache complicates this as you then need to keep track of whether the buffer
has been swapped or not already, and in some cases, which parts of the
buffer may have been swapped.
The approach taken by all other file systems that do this is to do on-the-fly
swapping. Whenever a metadata element that was read from storage is
referenced, a macro would be placed around the element to perform the byte
swap if necessary. For file systems with a fixed byte order, this can be
a compile-time define similar to the network byte order operations (htonl
et al). However, since ufs may need to swap order regardless of what
architecture it is running on, this turns into a conditional.
The sheer number of references to metadata elements make this byte swapping
operation highly pervasive. The initial implementation required a huge amount
of code change, and because we were redefining how accesses to basic file
system elements were done, any future modifications would also have to be
careful about using these access mechanisms. Also, because byte swapping
must be a conditional operation, performance degredation may be noticeable.
The bottom line: adding this support to ufs is not practical due to the
invasiveness of the changes, the limited usefulness of the feature, and
the difficulty of incompatible disk label formats between architectures.
I have attached a tar file containing the basic changes I made to ufs. This
is by no means complete, and I have never actually tested it to see if it
would work. I have included it here as a reference for a possible approach
in case anyone chooses to tacke this problem in the future. In the ufs
directory the *.bs files are the initial approach (byteswap on read/write
of metadata), and the checked out .c files are the more traditional
approach.
=========================================================================
No objection to the idea, just we have to keep in mind:
- we don't want to sacrifice native UFS performance
- we don't want to make changes to UFS that make it incompatible to old
existing filesystems
If you want to work on such a project, I could ask for the mentioned
prototype code, if retrievable, to be legally reviewed, whether it can be
released via the OpenSolaris ufs community.
FrankH.
Martin
This message posted from opensolaris.org
_______________________________________________
ufs-discuss mailing list
ufs-discuss@opensolaris.org
_______________________________________________
ufs-discuss mailing list
ufs-discuss@opensolaris.org
