From mboxrd@z Thu Jan 1 00:00:00 1970 From: peter swain Subject: supporting EAFS (a SCO sysv fs variant) under linux Date: Tue, 25 May 2004 00:00:48 -0700 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040525070048.GC8724@swine.dyndns.org> References: <20040520152320.45264.qmail@web21001.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="82I3+IH0IqGh5yIs" Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from rwcrmhc11.comcast.net ([204.127.198.35]:25252 "EHLO rwcrmhc11.comcast.net") by vger.kernel.org with ESMTP id S264790AbUEYHB4 (ORCPT ); Tue, 25 May 2004 03:01:56 -0400 To: C Iglesias Content-Disposition: inline In-Reply-To: <20040520152320.45264.qmail@web21001.mail.yahoo.com> List-Id: linux-fsdevel.vger.kernel.org --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Carlos, I don't have patches for 2.2.14, but would like to help by porting my support for SCO's sysv-fs variants AFS/EFS/EAFS and the associated 'divvy' partition table support to linux-2.[246], as I haven't touched it since 2.0, and haven't rigorously tested it since linux-1.3. Unfortunately I'm quite busy this week. [cc'd to linux-fsdevel in case anyone else has tools for this, or is interested in legacy filesys support] As I recall the whole linux sysv filesystem project needs to be ported forward -- there's much other useful compatibility code languishing there since KGB got distracted to other things (and me too). I don't have a SCO system to test against, nor even any known-good SCO EFS/AFS/EAFS filesystems, so if you'd like to send me a small test filesystem (perhaps containing the tree produced by the attached mk-sco-test) I could verify directory behavior when i get around to doing this porting, but I don't forsee much time to port it this week. Apart from the pre-PC partition scheme (divvy), there are two variants of sysv filesys here -- EFS allows filenames >32 chars, by chaining name fragments in consecutive dirent slots, with d_ino==-1 -- AFS replaces sysv freelists with inode & block bitmaps -- EAFS does both this was developed without inspecting any SCO code, to obtain access to ny data despite the undocumented filesystem format. Performance is not great, as you'd expect with a directory format which has so much messy handling, but it worked read/write quite reliably. sco 3.2r4.3 was the version that made the filesystems I was using, so you do have the right patcbes here. I don't know if you're familiar enuff with linux filesystem internals to port these patches, but vfs was vastly rewritten, and it will require some familiarity with old and new filesystem disciplines. I hope you're familiar enuff with patching and building linux kernels to build and test with a tentative patch, if i can come up with one. Probably worth creating a usermode tool to extract from a disk image, it's much easier to maintain, and nobody wants to *keep* their data in this format. Anyone know of such a tool for other filesys formats which I could extend for this, rather than reinventing wheel?? (no, not the dosfs tools, something civilized!) ^..^ swine@pobox.com (oo) On Thu, May 20, 2004 at 08:23:20AM -0700, C Iglesias wrote: > Hi Peter. > I am interested in Linux and i have seen > some contributions you have done in filesystems HOWTO > page > > I need to know how to access an EAFS filesytem type > from Linux > The stage is as follows: > SCO unix Ver.3.2,R4.3 ( older version because nither > TCP/ip exists in this system > The hard 4Gbytes capacity with EAFS filesystem type > > Also i have a Linux Mandrake 7.0 kernel 2.2.14-15mdk > with a Hard drive 20Gb and Ext2 filesytem type. > > I need to attach the sco hard drive with the linux > system in order to get out some data from SCO. > But i've not been able to mount the SCO into the > Linux > > I am sorry but i need you to know if you can help me > with this. > > I wil appreciate your help > Thanks and regards > > Carlos Iglesias > El Salvador, Central America --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=mk-sco-test #!/bin/bash ## test filenames of different lengths 1..255 ## the first part is bash-specific and not portable to ## (eg sco & xenix) other shells w/o research ## the real goal here is to build a tar file which can be ## extracted to a filesystem under test, and the results ## tar'd back up again to compare off-box with 'diff -r', ## checking for mis-named files or corruption ## don't be surprised if 'tar vtz' has names out of order, ## just make sure they're all created ## still haven't had time to look at code, i recall 255 being the ## E(A)FS filename limit. adjust if necessary. mkdir sco-test max=255 n=1; while [ $n -le $max ] do name=$(printf "%0${n}d" $n) echo $name > sco-test/$name let n++ done tar czf sco-test.tgz sco-test rm -rf sco-test --82I3+IH0IqGh5yIs--