Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!vic.news.telstra.net!act.news.telstra.net!psgrain!usenet.eel.ufl.edu!news-res.gsl.net!news.gsl.net!news.mathworks.com!newsfeed.internetmci.com!in2.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.solaris,alt.solaris.x86,comp.unix.bsd.freebsd.misc,comp.os.linux.misc
Subject: Re: BSD and Solaris's UFS (and FFS) compatable?
Date: Thu, 11 Jul 1996 23:15:52 -0700
Organization: Me
Lines: 165
Distribution: inet
Message-ID: <31E5ED98.2D8E75FB@lambert.org>
References: <ZYCHEN.96Jul3115400@sol19.cs.wisc.edu> <4rsvot$4fl@uriah.heep.sax.de> <4ru2k1$o87@mail.fwi.uva.nl>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Xref: euryale.cc.adfa.oz.au comp.unix.solaris:74727 comp.unix.bsd.freebsd.misc:23352 comp.os.linux.misc:115636
Casper H.S. Dik wrote:
]
] j@uriah.heep.sax.de (J Wunsch) writes:
]
] >Slowaris' UFS suffers from the incompatibilities that have been
] >introduced in order to support ACLs, and somebody on the mailing
] >lists reported that they are now incompatible enough so they
] >cannot be shared anymore, not even read/only.
]
] Solaris UFS is still compatible with oder versions if you don't use
] ACLs, so if you could share them readbefore you should still be able
] to do so unless yopu start using ACLs.
]
] BTW, you mispelled Solaris.
The 4.4BSD UFS is a newer version, not an older version.
It changes a number of time stamps in the superblock, both for
"volume last written" for support of Appletalk servers, and
several similar data fields.
In addition, the BSD 4.4 incorporates a "hint" field for file
type in the dir structure (I'm stll not sure if this is a
result of the suggestions I made at the time I was writing the
NWFS NetWare attributed FS variant of UFS, or if it was arrived
at independently).
The default behaviour of fsck is to compare the superblock fields,
and unfortunately, it does not ignore the "don't care fields"
when the do not match. memcmp()'ing the superblock.
This renders a 4.4BSD mounted UFS unreadable to Solaris, as it
incorrectly interprets the stamp fields as "corruption".
In addition, the enabling of ACLS *at all* damages the structures
used by 4.4BSD. Thus, even if ACL's are not used, the ACL
capability damages the 4.4BSD cross-mount capability.
The biggest problem is that Solaris and UCB both changed the FS
layout without changing FS_MAGIC from 0x011954 (if you are
clueful about FS's already, you will recognize this as Kirk
McKusick's birthday).
Arguably, this was OK for UCB to do because it is their code;
Sun had no such justification.
Here is a 4.4BSD vs. Solaris 5.3 (pre-ACL) comparison:
The Solaris field "long fs_id[ 2]" is jammed in the middle of
the superblock structure. This replaces the 4.4BSD fields
fs_headswitch and fs_trkseek, both safely ignorable optimization
values, in light of ZBR SCSI technology.
Where 4.4BSD has fs_qbmask, fs_qfmask, and fs_state, Solaris
has fs_state, fs_qbmask, and fs_qfmask (a gratuitous order
change and potential quad packing alignment issue).
The fs_sparecon[] field in Solaris is 55 32 bit values in
length; in 4.4BSD, the las 5 32 bit values are fs_contigsumsize,
fs_maxsymlinklen, fs_inodefmt, and a 64 bit fs_maxfilesize.
Solaris made the mistaken assumption that the spare field would
be used from the end, and uses the fs_sparecon[54] field (the
last 32 bits of fs_maxfilesize) for incore nanotime -- presumably
for NFS write gathering or similar timer based optimizations,
potentially including soft updates. It's unclear if this is
zeroed when written, or what is done about the destroyed data.
The correct place for in core fileds like this is in the FS
data hung off the mount structure, not the incore copy of
the superblock.
The significant fields here are the fs_inodefmt (incore inode
format, -1=BSD4.2, 2=BSD4.4) and fs_maxsymlinklen, which, if
non=zero, indicates use of link-in-directory and a change to
the on disk inode format. The fs_contigsumsize is not critical
if it is left alone. Obviously, a fsck would damage this,
and a Solaris newfs would not correctly initialize the cluster
summary array (which this field contains the size of).
The fs_maxfilesize is probably irrelevant, since the default
max file size will be > 32 bits on a 4.4BSD FS. The worst
that could happen is the value gets twiddled -- unless the
FS was created in BSD4.4, in which case, the file size could
be dramatically reduced into unusability, until you retuned
it using the 4.4BSD utility.
The directory entry structure in 4.4 in the 4.4 format case
divides the short d_namelen field into two unsiged char
fields, with the file type hints (as previously mentioned)
and an 8 bit d_namlen.
The 4.4UFS on disk inode (dnode, struct icommon in Solaris
and SVR4) is identical to di_gen (ic_gen). Solaris reserves
an ic_mode_reserv field on top of the 4.4 di_uid, and places
the uid on top of the 4.4 gid, and the gid on top of the 4.4
di_spare[ 0]. Solaris reserves an ic_oeftflag on top of
di_spare[ 1].
Clearly, you could distinguish the FS's by the contents of
the non-zero non-Solaris superblock... but it is not clear
that the fs_headswitch/fs_trkseek fields would not be
corrupted by Solaris, not is it clear that the low 32 bits of
fs_maxfilesize can be safely stopmed by Solaris, nor is it
clear that the Solaris fsck can safely act on a 4.4BSD fs.
Solaris does some bad things that it shuld not do.
One possibility, I suppose, would be to use the partitioning
to identify which is which. 8-).
Here are the additional differences for Solaris 5.5 (with
ACL's):
The Solaris 5.5 allocates the top half of fs_maxfilesize,
completing the destuction.
Clearly, the shadow inode structures would not be maintained
associated with the disk inodes for the files in the 4.4BSD
mount of the Solaris FS case.
Finally, I believe the ACL's conflict with the 4.4BSD use of
the file flags word for UF_NODUMP/UF_IMMUTABLE/UF_APPEND/UF_OPAQUE
and SF_ARCHIVED/SF_IMMUTABLE/SF_APPEND (and some others, which
I have defined locally, like "hidden" and "system" for use with
Windows95).
Does Sun have a clean way of identifying file systems with ACL
management present? The old/new field byte order and time
ordering is also suspect.
It would be nice if Sun picked another bithday (Larry McVoy's?)
for their FS magic number. My birthday is taken, since it was
used for NWFS...
Maybe 0x80011954, if you are loathe to honor Larry???
Compatability is an issue I'm prepared to deal with at a future
date, when it is possible (through devfs) to decode non-native
disklabel formats cleanly and transparently. The FS would
inherit the "SUN" label tag in internal processing.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.