Subject: fd0* device for ADFS shape discs under i386 Linux

From: Andrew Bower <[email-masked]>
Date: Thu, 16 Apr 1998 18:41:03 +0100 (BST)

I cannot find a device suitable for reading ADFS discs among the
standard shapes on my i386 distribution.  How can this be done please? 
I have compiled in ADFS support, but I can't even read the raw data off
the floppies. 

Out of interest, is anyone working on write support for ADFS?

Andrew Bower

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: James Craig <[email-masked]>
Date: Thu, 16 Apr 1998 20:16:13 +0000 (GMT)

>I have compiled in ADFS support, but I can't even read the raw data off

The bad news? You can't right now. The ADFS support right now is basically
for hard-drives, although if you can make up a disk image file, it should
manage with that just fine too.

I've patched up the floppy drivers on past versions of linux (1.2.xx) to
manage the trick, but looking over the current floppy drivers they've
changed a bit.

I haven't got time to fix the current 2.1.x ones to handle ADFS disks
myself - exams and the like - but it's certainly doable if someone is
feeling brave enough to tackle it.

The one problem I had when I was working on 1.2.xx kernels is that the
kernel doesn't manage to autodetect the sector size, so I was forced to
make either a 512-byte-sector-kernel or a 1024-byte-sector-kernel - if
someone does the patches on the current kernel, a more elegant solution
would be nice too.

hint for anyone brave enough to tackle it (from what I vaguely remember
from a few years ago): the FD_SIZECODE stuff in /usr/include/linux/fd.h is
the really important bit, but you'll need to watch buffer sizes and stuff
too.

Have fun all,

-- James Craig
   <[email-masked]>

---

From: Matthew Wilcox <[email-masked]>
Date: Fri, 17 Apr 1998 21:11:02 +0100 (BST)

Andrew Bower
> Out of interest, is anyone working on write support for ADFS?

I've looked at the current code.  It would be hard to add extendable
files to it, though in principle, files which are newly created and stay
the same length should be able to work quite easily.

The trouble is that ADFS (or more truthfully filecore) does not have
the concept of the inode.  Inodes are what Unix filesystems are built of.
They have the following properties:

Each file has an inode
The inode remains the same during the life of the file
Inodes do not map to more than one file.
The inode contains all of the metadata for the file except its name.

I cannot think of a good way of faking inodes for ADFS filesystems *except*
the following rather horrible idea:

Create a structure in memory for each ADFS filesystem mounted.  This can
be done lazily.  Assign each file an inode based on some scheme which will
allow for easy mapping between it and the name of the ADFS file.  Perhaps
hash buckets.  Note that it's okay to reuse inodes once a file has been
deleted.

Someone should look at other filing systems to see how they cope with
filesystems that don't provide nice inodes.  When Dickon Hood & I were
experimenting with NFS servers under RISC OS, we had a structure that
worked well; it was a tree, and the inode we returned was the address
within that list.  You've got me intrigued now, I might just do it.

The way Russell has done it is faster than this method for read-only
but will not extend to writable files.

-- 
Set Alias$Case Set Alias$[ |||| |MSet Alias$Otherwise Set Alias$[ \ Matthew
"" |MSet Alias$When If %0=%%0 Then Set Alias$[ "" ||MIf %0=%%0    \ Wilcox
Then Set Alias$Otherwise Set Alias$[ |||||||||||||||| ||MIf       \
%0=%%0 Then Set Alias$When Set Alias$[ ||||||||||||||||
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Alan Cox <[email-masked]>
Date: Fri, 17 Apr 1998 21:58:05 +0100 (BST)

> within that list.  You've got me intrigued now, I might just do it.

Several schemes are used. One of the cleanest if you stick to 2.1.8x+
is to issue inode numbers as you put things in the dcache and revoke
them as your inode is flushed. All open file inodes are in the dcache.

Alan

---

From: Vincent Renardias <[email-masked]>
Date: Fri, 17 Apr 1998 23:01:36 +0100 (GMT+0100)

> > Out of interest, is anyone working on write support for ADFS?
[snip]
> the following rather horrible idea:
[snip]

MSDOS' FAT system doesn't have i-nodes either, but they can be mounted r/w
anyway, so you may want to look at the kludge used there. (or in the
other non I-node based FSes recognized by Linux)

	Cordialement,

-- 
- Vincent RENARDIAS                 vincent@{waw.com,pipo.com,debian.org} -
- Debian/GNU Linux:           Pipo:                    WAW:               -
- http://www.fr.debian.org    http://www.pipo.com      http://www.waw.com -
---------------------------------------------------------------------------
- "La fonctionnalite Son Visuel vous delivre des avertissements visuels." -
-                          [Message durant l'installation de Windows95]:wq

---

From: Alan Cox <[email-masked]>
Date: Sat, 18 Apr 1998 01:12:22 +0100 (BST)

> other non I-node based FSes recognized by Linux)

A lot of kludging is done using block numbers, which works fine until you
hit an FS where blocks get moved around. smbfs implements a inodes on a
fs that has only path names stable

---

From: James Craig <[email-masked]>
Date: Sat, 18 Apr 1998 08:24:41 +0000 (GMT)

>The inode contains all of the metadata for the file except its name.
umm. ADFS doesn't have inodes in the same way UNIX does, but couldn't you
get away with the file's ID that appears in the free space map? (He said,
trying to talk knowledgably, despite the fact that it's 5 years since he
last wrote an ADFS-E-format-filing-system-reader).
The IDs still only map to one file, aren't likely to change over it's
lifetime, and the only problem you have is that the length info is kept in
the directory info.
>hash buckets.  Note that it's okay to reuse inodes once a file has been
Ur, YUK!! That would be horrible. I mean, mapping names to inodes is gonna
break as soon as you move a mile about the FS somewhere.
>within that list.  You've got me intrigued now, I might just do it.
Good man, writable ADFS would be nice. :)
>but will not extend to writable files.
I haven't looked at it yet, but what's he done that stops you writing
files the same way?

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sat, 18 Apr 1998 09:03:23 +0100 (BST)

> fs that has only path names stable

Ok, I think what I'll do at this point is supply a brief overview of the
structure of ADFS/filecore filesystem, such that everyone knows the
structure of the filesystem we're talking about.

----------------------------------------------------------------------------

Filecore, like DOS has two distinct structures, the directory and
effectively a map indicating allocation on the disk.  Under both, the
directory contains all information to do with a file, and the map tells
you where to find it.  This is, however, where the two diverge.

Filecore directories
--------------------

Under filecore, the directory contains:
	* Name
	* Load address		\ These days, they're combined into a
	* Execution address	/ filetype/datestamp.
	* Length
	* Attributes
	* File ID number

Directory entries are alphanumerically sorted and can have no gaps 
(ie, you delete a file, and all the other entries get shifted up one
position.

The ID number is the `key' to finding where the file is stored.  The ID
number on it's own does not indicate where the file is.  You need the
map to locate the file.  ID numbers refer to disk objects (fragment id)
and offsets within a disk object (sector offset).

Disk objects
------------

A disk object is similar to a file, but has a minimum size.  Several
files (normally with a directory) can be stored in a disk object, but they
don't have to be.

The map
-------

The map is basically a bitstream.  The map is partitioned into sector sized
zones.  Each map bit, relative to the first map bit indicates a set of sectors.
(this is defined in the boot sector, in the log2bpmb/log2_bits_per_map_bit).
A map entry consists of:

	+-------------+-------------+---+
	| fragment id | zero bits   | 1 |
	+-------------+-------------+---+

The fragment ID not only defines which entries to find, but which zone to
start searching the map.

The zero bits define the size of this fragment.

Free blocks are indicated by a linked list of these blocks.  In this case,
the `fragment id' is the offset to the next free block in this zone, or zero
if this is the last.

----------------------------------------------------------------------------

This allows filecore to automatically defrag the disk on the fly, since
it doesn't need to find the directory associated with the file - it just
changes the map.

The reason that the Linux adfs isn't able to be writable is indeed the way
that it allocates inode numbers.  Inode numbers are currently defined to
be the directories fragment ID << 8 and the entry offset within that
directory.

----------------------------------------------------------------------------

There you have it...  Hope it's useful. ;)
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sun, 19 Apr 1998 11:46:42 +0100 (BST)

> last wrote an ADFS-E-format-filing-system-reader).

I did toy with that idea, after all,  it is quite unique.  However, you stumble
on a small problem:

Under Unix, a filename translates to an inode.  An inode then gives you the
file data, and attributes.

Under Filecore, a filename translates to a fragment ID + attributes.  A
fragment ID translates to file data.

Hence, if you do use the fragment ID for the inode number, then yes, you can
access the file's data, but you can't get the inodes attributes, since you
don't know where these are stored on the disk.

I did at one point use a combination of the fragment ID for the parent directory
and the fragment ID of the file, but 32-bits isn't enough to store this and
the sector offset required.

This method still isn't acceptable for a writable ADFS - if the file is moved from
the directory to another, then it's parent ID changes...

> lifetime, and the only problem you have is that the length info is kept in

Exactly.

> break as soon as you move a mile about the FS somewhere.

I think that this is horrible, but may be the only way.

> I haven't looked at it yet, but what's he done that stops you writing

The problem is that the inode number depends on the position of the directory
on the disk and the offset into the directory.  If you add a file, then
as far as the Linux VFS is concerned, all the inodes on that disk have changed,
and all inodes must be refreshed.  NFS will go mad (since it depends on inodes
staying the same), as will things like `pwd'.

Linux needs to be able to map an inode number directly to a file on ADFS -
this is the first problem that someone's going to have to crack when allowing
ADFS to be writable.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: James Craig <[email-masked]>
Date: Mon, 20 Apr 1998 10:57:37 +0100 (BST)

> the directory to another, then it's parent ID changes...
Yeah, I can quite definately see the problem. However, could we store a
hash table of recently-accessed-inodes and just cache their directory
info? It's not like you can't search and ADFS filesystem for a particular
ID, it just takes a while. For small enough numbers of files, (say a
floppy) you could do it at mount/umount time.

> I think that this is horrible, but may be the only way.
How would it handle mv /bin/testfile /tmp/testfile, though, if the file
was still being read by another process?

> this is the first problem that someone's going to have to crack when allowing

Truly. I've written ADFS file readers and writers before, but I've never
tried integrating one into a totally different OS's idea of a filing
system. In the meantime, we could probably fairly quickly code up an ADFS
equivalent of the mtools for DOS - The old IscaFS that Phil Norman wrote
would do the job just fine if we could manage to fiddle it to run under
Linux. :)
-- James Craig
   <[email-masked]>

---

From: Matthew Wilcox <[email-masked]>
Date: Tue, 21 Apr 1998 05:23:35 +0100 (BST)

Alan Cox
> them as your inode is flushed. All open file inodes are in the dcache.

I don't have a problem with something being only valid for 2.1.8x+ linux,
after all 2.2 will be soon enough.  However, would this scheme not screw
NFS rather badly?  I thought inodes had to persist for the lifetime of the
file.  NFS has the rather nasty requirement of having to preserve them
over reboots.  [I've implemented an NFS server for RISC OS.  It is nasty.
You may see it released rsn if certain other things happen.]

---

From: Matthew Wilcox <[email-masked]>
Date: Tue, 21 Apr 1998 05:36:30 +0100 (BST)

James Craig
> floppy) you could do it at mount/umount time.

Here's the system I used for TermiteNFS.  It was optimal for that
application; I'm not sure which operations are applied to Linux's inodes:

pointer to parent
pointer to younger sibling
pointer to first child
leafname

The inode is simply the offset within the block.  You can find the full
pathname of a file in O(log n), and you can enumerate a directory in a
straight-forward manner.  Renaming an object does not change its inode and
requires changing 3 pointers.  Directory information is already cached in
the dcache, it's a matter of being able to find it efficiently when it's
no longer there.

Now, if the ADFS filesystem is not modified over a reboot, this data could
be stored on disc and we've managed to fulfill the requirements of NFS.
Yuck.

> would do the job just fine if we could manage to fiddle it to run under

Uhh.. IscaFS reads ext2 filesystems from RISC OS.  So does ExeterFS
(IscaFS is an image filesystem and is extremely sexy.  ExeterFS is more
like Spark and has a number of bugs.)

---

From: James Craig <[email-masked]>
Date: Tue, 21 Apr 1998 09:56:56 +0100 (BST)

> > floppy) you could do it at mount/umount time.
<snip>
> like Spark and has a number of bugs.)
Yep, sorry all, I was seriously confused when I wrote that bit.
I'll just go shoot myself. ;)
I think the next best thing I have is a set of old ADFS E-format
readers/writers I wrote for the BBC B+ in BASIC. Time to get to work on
them again. :) 
BTW, anyone know - ARM linux OK with 4 floppy drives on an A410/1?
Must try tying that in sometime, and seeing what happens. :)

--
James Craig <[email-masked]>
            <[email-masked]>

---

From: Alan Cox <[email-masked]>
Date: Tue, 21 Apr 1998 10:32:25 +0100 (BST)

> You may see it released rsn if certain other things happen.]

So you cant export them back out via NFS (ditto for SMB back out via NFS
already). Is that a big issue ?