In message <[EMAIL PROTECTED]>, Jeff Quast writes: > On 9/5/06, Igor Sobrado <[EMAIL PROTECTED]> wrote: > > Hello! > > > > I am trying to understand an odd behaviour in the Berkeley Fast File > > System as implemented in both NetBSD and OpenBSD. My main concern > > > [...] Can it be > > a problem when sharing these drives with non-i386 architectures? > > Guessing that you are sharing files between big-endian and non-endian > machines?
Quite sure! I am certainly worried about big-endian and little-endian architectures. Sometimes a fix appears that allows a driver (usually written for i386 architectures) working on big-endian architectures. It works for drivers but, obviously, a filesystem is very different. We cannot make a filesystem "endianess independent" as it will make the new version of the filesystem incompatible with some architectures. > You can't do that with ffs. These are bad news, but at least I hope that sharing filesystems between NetBSD and OpenBSD *on the same architecture* will be possible. Something like the Berkeley sockets API functions to convert integers to network byte order would be too expensive for a filesystem, though. Ok, then the second question remains. Why a ffs filesystem created on a HDD added to an OpenBSD system cannot be mounted on NetBSD? To be more precise, I cannot assure that a "ffs filesystem created on OpenBSD cannot be mounted on NetBSD", I am guessing that the problem is in the BSD disklabel instead. Is making the BSD disklabel and filesystem on NetBSD the right answer to this problem? (it is the workaround I found when looking at the problem some days ago.) Can we expect other problems related with sharing these storage devices between both operating systems? I think that these external drives (mainly the 80 GB HDD) are not only an excellent way to share data -I certainly prefer using a local network for these purposes, it is faster and more reliable- but excellent media for storing data. But, to be *really* useful, I will need to share these filesystems between both operating systems. FAT32 is not the right answer to this problem. > NetBSD apears to have the option FFS_EI. That may help. A quick search > indicates that nfs & vnd trickery may be required. Excellent advice! Certainly nfs has not endianess issues and the useful vnode driver can help in this matter in the same way it helps when mounting disk images (the first time I used vnd was mounting a disk image stored in a local disk... in few minutes I discovered that vnd is elegant and powerful, as the BSD operating system themselves.) But it is perhaps too complex, better staying at a single architecture. Certainly restricting ffs mounts to a single architecture is not a problem at all, but I would greatly appreciate some advice on the second question: why a disk created on OpenBSD cannot be mounted on NetBSD, if it is a known problem -or not a problem at all but an expected behaviour- and if we can safety share a filesystem created in NetBSD with OpenBSD. If it is a known behaviour of two different ffs implementations, I will need to make two sets of USB drives: one for NetBSD and other for OpenBSD and sharing files using scp. If it is a problem and it is currently not documented, I will do my best to provide as accurate information as possible in a problem report. Best regards! Igor.
