Subject: The Joys of Linux

From: Simon Glass / Linux <[email-masked]>
Date: Thu, 15 Oct 1998 20:33:56 +0000 (GMT)

Hi,

I finally bit the bullet and installed Linux last night. What a bullet it
was. Without being able to search through archived mail it might have taken
me a week...I think an X-Files extractor for Linux would be handy.

I'm amazed by all the software there, and the reliability of everything. BTW
I also have a Netwinder (nice but no s/w yet), plus Linux on a PC (I boot
this up when Windows crashes to restore my faith in mankind).

I do have one minor problem though. I have a second disc drive which is a
2.7GB Maxtor 72700AP (5248 cylinders, 16 heads, 63 sectors). At the moment I
have to unplug it otherwise Linux crashes on boot-up (cursor stops flashing)
after finding all the drives. I remember RISC OS having this problem years
ago with a 420MB Conner drive.

So I have to disconnect the drive & type 'configure idediscs 1' before
running Linux. A small price to pay.

I see several people have reported similar problems - any solutions yet?

Also, is anyone working on a read/write adfs for Linux or ext2 for RISC OS?

Regards,

-- 
Simon Glass
Austin, Texas

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

---

From: Phil Norman <[email-masked]>
Date: Fri, 16 Oct 1998 14:41:35 +0100

In message <[email-masked]>

> Also, is anyone working on a read/write adfs for Linux or ext2 for RISC OS?

Currently there's read-only adfs is linux, and read-only ext2 in RiscOS,
which covers both directions, but isn't ideal.  I would possibly have started
adding write-ability to IscaFS (the read-only RiscOS ext2-reader, URL in
the sig), but I don't have spare time, and the need is not great enough to
warrant it.  I'm far more interested in designing my own filing system, which
is good fun (whether I'll ever get around to implementing it is another
matter ;-).

Phil

-- 
http://newton.ex.ac.uk/general/ug/norman/
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: James Craig <[email-masked]>
Date: Fri, 16 Oct 1998 14:49:20 +0100 (BST)

> me a week...I think an X-Files extractor for Linux would be handy.
I have one. Trying to remember who wrote it......
Nicholas Clark, I think. It's called XRec - X-files recoverer. I was asked
not to distribute it, though, I'm afraid. 
> this up when Windows crashes to restore my faith in mankind).
Windows ever *boots* on your machine? WOW! I'm impressed. You must have
truly incredible patience!
> Also, is anyone working on a read/write adfs for Linux or ext2 for RISC OS?
Both are works-in-progress - IscaFS for ext2fs and Russ has ADFS support
to some extent (read-only still, I think) in the kernel.

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

---

From: Matthew Wilcox <[email-masked]>
Date: Fri, 16 Oct 1998 18:03:38 +0200

> Also, is anyone working on a read/write adfs for Linux or ext2 for RISC OS?

A read/write ADFS doesn't really seem interesting any more, now that
Acorn have dropped their Workstations operation.  There's IscaFS
for RISC OS which lets you read ext2 partitions - download it from
ftp://ftp.barnet.ac.uk/pub/Acorn/armlinux/iscafs/iscafs.zip If anyone
wants to add writing support, I don't think this will be extremely hard
to do.

-- 
Matthew Wilcox <[email-masked]>
"I decry the current tendency to seek patents on algorithms.  There are
better ways to earn a living than to prevent other people from making use of
one's contributions to computer science."  -- Donald E. Knuth, TAoCP vol 3
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sat, 17 Oct 1998 08:53:08 +0100 (BST)

Matthew Wilcox writes:
> Acorn have dropped their Workstations operation.

I don't really see r/w ADFS as a viable proposition really, due to the way
that an ADFS filesystem is layed out and the way Unix filesystems work in
general.  They're totally different beasts.

To highlight the problem:
- ADFS stores all information about a file in the directory containing that file
  (object id, length, attributes etc).  This is referenced by name.

- Linux uses what are called inodes, with a number.  This number uniquely
  identifies a file/directory on the disk.  To get all the information about
  a file under Linux, the filesystem is asked for the following.

  1. What is the inode number of this object?
	(eg, RISC OS path: ADFS:$.Library.cc Linux: /Library/cc -> some number)

  2. Please give me all the information about the object defined by this
     inode number.

  The first is easy to do, but the second is not.  Currently, the Linux ADFS
  filesystem uses as an inode number the disk object ID of the directory and
  the entry number in the directory.  This is fine when the filesystem is not
  writable, because you can guarantee that all the directory entries will not
  move.

  However, when you introduce writing, mapping 2 breaks down since you can no
  longer make this guarantee.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Phil Norman <[email-masked]>
Date: Sat, 17 Oct 1998 13:24:25 +0100

In message <[email-masked]>

> wants to add writing support, I don't think this will be extremely hard

It's also not very easy.  Don't be fooled into thinking that write support is
just like read support, but the other way.  Writing will involve some fairly
complicated functions (there's a tiny amount of support already written, but
it hasn't been tested at all and is nowhere near enough support to get even
the simplest write functions fully implemented).

If anyone wants to try adding write support to IscaFS, PLEASE talk to me
about it first.  There are some nasty bugs in the cacheing system which don't
appear at all when just reading, but could cause SIGNIFICANT data loss if
applied to read/write code.  I have designed a cacheing system which will
overcome this and also be a fair bit faster, but haven't written it yet.

Cheers,
Phil

---

From: Alan Cox <[email-masked]>
Date: Sun, 18 Oct 1998 02:27:27 +0100 (BST)

>   (object id, length, attributes etc).  This is referenced by name.

Yep

>   writable, because you can guarantee that all the directory entries will not

There is no need for inode numbers to be stable across opens. Just stable
while active. smbfs is path based and works fine. With the dentry cache
in 2.1.x its far far easier to do. 

Alan

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sun, 18 Oct 1998 09:49:07 +0100 (BST)

> in 2.1.x its far far easier to do. 

However, since ADFS directories are sorted in alphabetical order, any rename
in said directory will cause the inode number as it is currently generated
to change.

In previous versions of ADFS, there was a sequence number stored with the
entry, which was used by the 6502-series machines to track the directory
entries for this very reason.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Dave Gilbert <[email-masked]>
Date: Sun, 18 Oct 1998 12:23:58 +0100 (BST)

While it would be really useful to be able to write new files etc to the
ADFS filesystem, a REALLY useful full step would be to allow modification
of the data in an existant file (without modifying its length).  That
would allow people to write to DOS filesystem images and also swap to an
ADFS partition.

Dave
 --------------------------------------------------------------------   
/ Dr. David Alan Gilbert      | Running Linux on Alpha(LX) |  Happy  \ 
\   gro.gilbert @ treblig.org |   & ARM(EBSA285,old Arc)   |  In Hex /
 \____________________________|___ http://www.treblig.demon.co.uk __/

---

From: Alan Cox <[email-masked]>
Date: Sun, 18 Oct 1998 15:17:39 +0100 (BST)

> in said directory will cause the inode number as it is currently generated

And Smb namespace changes remotely as its a file sharing protocol. Big deal
it doesnt cause a problem
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sun, 18 Oct 1998 15:20:15 +0100 (BST)

> would allow people to write to DOS filesystem images and also swap to an

That can already be done - you can mount the ADFS filesystem read/write,
so that the loopback device can write to the contents of a file for this
very reason.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Timothy Baldwin <[email-masked]>
Date: Sun, 18 Oct 1998 15:38:45 +0100

In message <[email-masked]>
          Alan Cox <[email-masked]> wrote:

[snip about ADFS]

> >   Currently, the Linux ADFS filesystem uses as an inode number the disk
> >   object ID of the directory and the entry number in the directory.
> >   This is fine when the filesystem is not writable, because you can
> >   guarantee that all the directory entries will not move.
> 

The inode problem is solvable by ensuring the directory entry contains
either the reference to the same file or a pointer to the real directory
entry. (The contents of unused directory entries is undefined).

The big problem is the allocation of space:
Disc objects may be fragmented, but each fragment has a minimum size and
fragments must be kept in order on the filesystem. Disc objects can contain
many small files in the same directory (and the directory) or be one big
file.

This means it may be necessary to move data on the filesystem, including
defragmenting the filesystem, on file extension, creation and rename
between directories.
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Matthew Wilcox <[email-masked]>
Date: Sun, 18 Oct 1998 20:54:33 +0200

> would allow people to write to DOS filesystem images and also swap to an

This already works.  I can't take any credit for it; all you need to do
is delete all the references to RDONLY within the source to the ADFS fs.
I believe Russell has done so for the latest versions.  You can write
to image files such as the DOS partition file or an ext2 image (this is
how my linux-without- partitioning concept works.  See my web pages,
http://pocket.fluff.org/~mrw/armlinux/ for details).  Beware that for
DOS images, you need to skip the partition table at the start; so you
want something along the lines of:

losetup -o 7680 /dev/loop2 /mnt/adfs/Emulators/Drive_C

This works just fine for me.

(For those that are interested; the loop device works by calling the
bmap function which was already implemented.  So this is slightly
different from calling the write function which is not implemented,
so will return an error.)

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sun, 18 Oct 1998 20:24:22 +0100 (BST)

> entry. (The contents of unused directory entries is undefined).

No, as I keep on saying, if you delete an entry, or rename an entry the order
changes, and so the physical location of said directory entries change.

At the moment, any change in the current directory structure will cause
chaos in the current implementation of adfs under Linux.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Timothy Baldwin <[email-masked]>
Date: Mon, 19 Oct 1998 11:07:35 +0100

In message <[email-masked]>
          Russell King - ARM Linux Admin <[email-masked]> wrote:

> However, since ADFS directories are sorted in alphabetical order, any
> rename in said directory will cause the inode number as it is currently
> generated to change.

Although ADFS maintains directories in alphabetical order, the order
is not specified, therefore the Linux adfs filesystem need not maintain
the order.

I have verified that the order does not matter by experimentation.

I have also verified that the contents of unused directory
entries does not matter.
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Ian Jeffray <[email-masked]>
Date: Wed, 21 Oct 1998 15:39:27 +0100 (BST)

I'm still having no joy with my Acorn SCSI card (rev 2).
fdisk appears to have worked ok and created a couple of partitions for me
(sda1/sda2), however, mke2fs bombs out with an address exception error,
then abotu 10 seconds later I get a lot of spam about "SCSI host 229 not
responding" and "Aiee, removing interrupt handler" etc.  Clearly something
is wrong if it thinks there's a host 229 (it should be '7' of course).

I'm running on an 8MB A540, with the very latest kernel 2.0.35
READING from a scsi disc seems to be ok (I can read my 'initrd' via
loopback from the scsi drive, and the scsi cdrom works just fine...)

Help! Please?

Ian
-- 
Ian Jeffray // Tel: 0131 337 9923 // Mobile: 0378 392 963 // [email-masked]