Anyone knows whether it is possible to mount EAFS (SCO ODT 3.0)
filesystems from Linux? If so, how?
If not, are there available the EAFS specs for me to have a go at EAFS
linux module?
Regards
George Vicherek
geo...@ied.com
Here's what I got from William Bader earlier this year, regarding EAFS
and Linux:
--- { ---
> Sounds interesting. I assume Linux *app*, not *filesystem*. Could you
> point me to those sources, please?
It is a filesystem. Linux supports virtual filesystems, so it is
relatively easy to write drivers for new filesystem types.
I found the posting in my notes. It looks like it supports only sco
3.2v4, and not the new v5 filesystems. I am not sure how much sco
changed the format to support logging. I suspect that sco did not
change it much from EAFS, but you can never tell.
William
--------------------------------------------------
From sw...@opera.iinet.net.au Sat Apr 19 15:24:30 1997
From: sw...@opera.iinet.net.au (Peter Swain)
Subject: sco_fs - read/write access to SCO's modified sysv filesystems
Newsgroups: comp.os.linux.announce
Date: Thu, 17 Apr 1997 8:32:39 GMT
At http://www.iinet.net.au/~swine/sco_fs you'll find a few patches to
the sysv_fs and genhd.c code to allow use on SCO3 (v3r2.4) filesystems
(i don't know about OpenServer5, i've never met one). Thanks to Bruno
Haible <hai...@ma2s2.mathematik.uni-karlsruhe.de> for the basic sysv
filesystem code.
Should appear as
http://sunsite.unc.edu/pub/Linux/system/filesystems/sco_fs.lsm and
13-sco_fs-0.1.tgz and 21-sco_fs-0.1.tgz in a coupla days.
By inspection of SCO-generated filesystems (while trying to extract my
data from them), i've deduced that SCO differs from the basic sysv4
filesystem in several areas:
- - 'divvy' partitons
SCO has its own unique brand of extended fdisk partition,
with type 0x63 (same as GNU HURD!).
The divvy table lives 22K into the base partition
and carves that partition up into sub-partitions
called divvy-partitions (divisions) after SCO's divvy utility.
The start+end addresses of these are relative to the *next*
cylinder boundary (or maybe even the next after that, in some
cases! (where cylinder contains odd number of sectors))
- - AFS filesystem
like sysv4, but using bitmaps instead of the chained free-list
of blocks (though the inode freelist is unchanged).
This is signalled by an s_free count of 0xffff.
- - Extended File Names
The sysv (SCO calls it S51K) and AFS filesystems may be
'extended' to handle names up to 255 chars (rather than 14).
These filesystem types are called ES51K and EAFS.
Directories entries still have 14-char names (a la sysv),
but they're chained by using an inode number -1 for
non-terminal chunks, which form a prefix to the next entry.
This behaviour is signalled by adding 1 to the super-block
magic number (which becomes 0xfd187e21).
SCO3's default filesystem type is EAFS, but if you convert filesystems
to ES51K, it runs fine (just saying 'Extended File System' instead of
'Extended Fast Filesystem' when it does an fsck).
Don't know about SCO5, i've never met one.
I've addressed these differences as follows:
- - EAFS & AFS filesystems can be mounted read-only to leave them
unmolested, or mounted with "mount /dev/hda5 -t sysv -o
convert_afs", which zaps the bitmap freelist, leaving an ES51K
or S51K filesystem, which SCO will handle without you noticing
any difference (maybe 5% slower, and you'll have to use fsck to
rebuild the freelist next time you run SCO on that drive
[or run "/SCO/etc/fscmd.d/ES51K/fsck -f -S /dev/hda5" under ibcs2]
- - Extended names are handled throughout (when the super-block
implies they should be), so the 14-char limit disappears, and any
long names which appeared fragmented under the old filesys now
join up again.
- - CONFIG_SCO_DISKLABEL adds "divvy" support to genhd.c,
recognising divvy partitions on a sco-formatted drive,
and calling them (say) hda5, hda6, ...
This is necessary if you wish to boot from a SCO drive.
Divvy parallels the function of DOS's Extended Partitions
(but evolved for Xenix before DOS developed the concept).
- - Divvy partitions are also detected by hdinfo_sco,
(modified from dosemu's hdinfo util), allowing sco_fs patches to be
restricted to fs/sysv module: hdinfo_sco yields a
byte-offset-to-filesys, so you can use "mount -t sysv
-oloop,offset=XXXX /dev/hdb /mnt".
Using SCO filesystems from both SCO and Linux:
The bitmapped-freelist EAFS (SCO3 default) filesystems are
detected, and forced read-only as the freemaps aren't understood,
which makes a *much* faster common-filesys-format than SCO3's DOS
fs (which does a woeful 120kB/minute on a 33MHz 486!)
Read/Write ES51K works too, and you can then boot Linux or SCO
off the one partition (with iBCS2, and a bit of juggling symlinks
on /etc & /dev). (Just takes one quick jab with fsdb to convert a
filesys from EAFS (ro by linux) to ES51K (rw by both, and mebbe 5%
slower), or you can mount with -oconvert_afs)
EAFS is a combination of AFS (bitmapped free list on an otherwise
S51K fs), and Extended names (255 chars rather than 14).
SCO supports both intermediate forms (ES51K & AFS), so you don't
notice a thing (except the SCO-fsck banner of "[Extended] [Fast]
File System").
History:
I've used this code for well over a year w/o hiccups, but haven't
had access to SCO systems to preen it against in most of that time.
Still has a few ruff edges which i've never bothered cleaning up
(haven't adopted the new prinkt() levels, etc)
and contains an overblown mount-option-parser,
but my original 1.3 patches (done on 1.3.96) drop seamlessly
onto 1.3.62, and without much hand-tweaking onto 1.3.42 or before.
Recently I pulled out an old SCO-generated filesystem and checked
that it still worked with linux-2.1.30. Coupla trivial .h changes,
and it performs as ever.
The sco_fs-2.1.tgz patches should apply w/o hiccup to 2.0.0 ...
2.1.33, i think.
Some warnings about extended names are left enabled in fs/sysv
code, please give me some feedback on whether you have any hiccups
in this (or any other) area. Consider it Beta -- works for me but
I may have missed a few things.
--- } ---
--
Radek Tomis
r...@medium.cz