Daniel Rock <[EMAIL PROTECTED]> wrote:
> > Why do you believe this, do you have any prove for this?
>
> There are many other sites which cite Kirk as primary author of FFS. But
> Kirk himself is more humble about it:
>
>
> - Bill Joy did the first design of FFS. I implemented his initial design
> - filling out the missing bits with my own ideas. So, I consider it to be
> - a joint design by Bill and myself. I have done all of the additional
OK, so far. From the information I have, it was a joint Master Thesis
from Bill, Kirk & Samuel Leffler.
> - work on the filesystem since that time which includes dynamic block
> - reallocation, soft updates, snapshots, and most recently the change
> - to 64-bit block pointers to support multi-Terabyte and larger filesystems.
Well, this is not really true as this is work that has been done
for FreeBSD _after_ FreeBSD did decide not to start with a recent version
of 4.2FS/UFS/FFS in 1993, but to go back to a ~ 1985 version which was similar
to the 1982 version and go into a different direction than the code did go so
far.
> > In the early 1990s, FreeBSD did not follow the changes made by Sun:
> >
> > - Allow more than 32 cylinders/group by adding dynamic rotational tables
> > SunOS-4.0 (1987)
>
> Mostly irrelevant. The default is still 16 by mkfs/newfs. To get much larger
> values you have to cut down the number of inodes dramatically.
If you are talking about FreeBSD, this would only prove that FreeBSD
still uses the old (Pre-SunOS-4.0) version.
With a UFS version from SunOS-4.0 (1987) or later, newfs of course and
even by default uses bigger values (depending on the geometry and size
of the disk). BTW: The number of inodes/cylinder group is unrelated
to the number of cylinders per group.
> Besides: Is fs_cpg still used today? Its information is redundant and it
> seems to be ignored on both Solaris and FreeBSD.
If the value is low enough to match the numbers from 1982, SunOS-4.0
did create a compatible FS. If the value was larger, dynamic rotational
tables have been used. I believe that the rotational tables are no longer
used with a recent Solaris.
> > - Implementing the long planned clean flag
> > SunOS-4.1 (1989)
>
> fs_clean was already in FreeBSD 2.0, although with a slightly different
> semantic (only clean/dirty).
This is what I said: The clean flag was always in (but unused).
SunOS-4.1 did introduce it around 1989.
FreeBSD did introduce an incomatible implementation after 1993..
> > - Extended fundamental types in the inode.
> > Solaris-2.0 (1990)
>
> see below
>
>
> > - Shadow inode extensions for ACLs
> > Solaris-2.3 (1993)
>
> Like I said. The introduction of a shadow inode shifted the 32 bit uid/gid
> values back 4 bytes in Solaris. So if you fsck'd a FreeBSD UFS disk in
WRONG: Nothing did shift caused ny the shadow inode.
SunOS-5.0 (~1990) did _add_ EFT variants of the numbers at a different
place. If the values did fit in a short, the old locations have still been used
to allow to move a disk between SunOS-4.x and SunOS-5.x.
If the values did not fit, the EFT-Flag had been set to 0x90909090 and the
extended values have been used.
If you did not know how this was done, you may have believed incorrect
things...
If you look into the new include files, you see that the old places for
the non-EFT version and even the EFT-flag are unused now.
> > The fact that FreeBSD did not follow these changes was the biggest problem
> > with drifting.
>
> But making Solaris' and FreeBSD's basic UFS (from the mid 90s, no ACLs)
> compatible again should be an easy task - at least easier than making UFS
> endian aware.
In the mid-1990s, The main changes of UFS have all been ready...
Even ACLs have been ready in Solaris-2.3 (1993) alrerady, you only did
need to use the syscall directly - the userland libs were missing.
Solaris never has been using the old UFS that FreeBSD did start to
go into a different direction.
> >>back in the earlier days (Solaris 2.4/2.5) the file systems were almost
> >>compatible:
> >
> >
> > This is not true, see above. All important changes I mentioned have been
> > done before intriducing Solaris-2.0.
>
> I have done it back these days several times. I used an UFS formatted ZIP
> disk for data exchange between FreeBSD and Solaris/x86. It was far from
> perfect, but it worked at least for regular files and directories. I didn't
> have any intention for using more features.
If you did do the exchange between FreeBSD and an old Solaris version that
still did use ic_oeftflag, you may have had more luck then now.
> >>1. The Solaris superblock had two fields swapped (you can still see it in
> >> the header files)
> >
> >
> > Which ones?
>
> Search for
>
> #ifdef _LITTLE_ENDIAN
>
> (fs_state, fs_npsect)
OK, this sems to be a result of the SVr4 integration.
AFAIK, SVr4 did start with the SunOS-4.0 sources which did not
yet include FS-clean handling.
> >>2. Because of the introduction of a shadow inode (for ACLS) the uid/gid
> >> entries in the inode are shifted between Solaris UFS and FreeBSD UFS1.
> >
> >
> > No: Because the extended fundamental types introduced with Solaris-2.0
> > (which is long before FreeBSD did start), new fields have been introduced
> > for uid/gid and st_rdev.
>
> The 32 bit values for uid/gid have also been on FreeBSD's UFS for a long
> time, just at a different offset. Below is an excerpt of a inode stored on
> disk in FreeBSD and Solaris. Up to offset 112 both are identical:
And this is a result of FreeBSD ignoring the changes that have been
made to support the EFT values with SVr4.
> So even the chflags are still present in Solaris' UFS, although not used.
I hope it will be used in the future.
> And for rdev: Of course I didn't use special files on these file systems for
> data exchange. They would have been incompatible anyway. Or what did you
> mean with st_rdev?
Sorry, I was confused: st_rdev of course is in ic_db[0].
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
