AFS0 Bitmaps

discussion of beeb/electron applications, languages, utils and educational s/w
User avatar
BeebMaster
Posts: 2475
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

AFS0 Bitmaps

Postby BeebMaster » Sun Jul 30, 2017 9:16 pm

I've spent the last few weeks trying to get a "huge" hard drive working with my FileStore E01, with SCSI2SD. When I was working with the E01S and SCSI2SD last year I only went as far as recreating a 40MB drive as close as possible to the E40S spec, more to prove it could be done than anything else.

A few years ago I devised a geometry which seems to work well in CF/IDE drives using the Level 3 File Server whereby the maximum ADFS disc size (512MB) could very nearly be achieved, and 4 drives could be available at once, giving 2GB of Econet storage.

That was 1057 cyl, 62 head, 32 sectors per track.

The AFS0 Econet file structure manages free space in the file server by reserving the first sectors in each cylinder for free space bitmaps. One bit is allocated for each sector, so for a single sector to be used, there must be a maximum of 8 x 256 = 2048 sectors per cylinder. 62 x 32 was about as near as I could get without going over.

The AFS0 layout stores the number of sectors per bitmap, so in theory 2 or more sectors could be reserved for the bitmap. However, this doesn't appear to be supported in the L3 file server or FileStore.

There are parts of WFSInit (seemingly also FServInit, although I don't know my way round that as well as WFSInit) that assume only 1 sector is being used for the bitmap - so when it writes the NFS 1st sector and NFS 1st sector copy, it puts them in sector 1 of the cylinder, overwriting the second sector of a 512-byte bitmap, and writes the root dir and passwords file's map-chain in sector 1 as well.

I've modified WFSInit so it correctly allocates these files when there is a 2-sector bitmap, but the disc never mounts properly. Instead of reading all the bitmaps into RAM, shown by a significant delay and the SCSI2SD light flashing (or a horrendous worrying clanking sound as the head steps all the way all the platter if using a real Winchester disc), there is just a brief disc access and the server starts. Reading the disc free space then shows that nearly all the disc is allocated as used, with only a few 100K free.

In addition the FileStore seems to have much less memory free for holding the bitmaps than the L3 server. I found using my 1057 x 62 x 32 formula with the E01 just wouldn't work - as soon as you log on after the FileStore starts, you get FS Error 3C, which is cache full.

After a great deal of experimentation I found that the largest "disc" I can get FileStore to support is about 250MB, with 480 x 16 x 125 appearing to be the optimum geometry. Even then, I can only get one disc running, try initialising a second 250MB disc and the 3C error comes back.

It may just be that the FileStore doesn't have the memory to take all the bitmaps for a combined set of storage in excess of 250MB. I can probably live with that, but what I can't fathom is why both FileStore and L3 server completely ignore the bitmap-reading stage when they know it's a 2-sector bitmap.

All ideas gratefully received!
Image

User avatar
jgharston
Posts: 2764
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: AFS0 Bitmaps

Postby jgharston » Sun Jul 30, 2017 11:44 pm

In my documantation I wrote:

An allocation map is documented as being able to occupy more than one
sector, but I have not found out how the other sectors in the map chain are
pointed to. This is likely to be a documentation error as a single sector
can easily hold an allocation map for the maximum 8M file.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
BeebMaster
Posts: 2475
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: AFS0 Bitmaps

Postby BeebMaster » Sat Aug 05, 2017 7:56 pm

Ahh- sorry, I was on about the free space sector bitmaps at the beginning of each "cylinder".

Something inside the file server code seems to take exception to learning that the bitmap is 2 sectors long, and instead of reading the bitmap stored on each cylinder, it more or less skips the whole lot and decides the disc is almost full.

Incidentally, I think it's possible that a "JesMap" allocation map for a file could take up more than one sector. There are 5 bytes needed for each part of the map chain, 3 for the sector address and 2 for the number of sectors in that part of the chain, so with a bit of header information taking up a few bytes in the map sector, that's around 50 chains per map sector. It's feasible (but unlikely) that a single file could be stored in more than 50 separate locations.

And I've found that the 8MB or 16MB (depending on what file server and what you read about it) maximum Econet file size can be exceeded; using a CF drive with the L3 server I've created files much larger than that. At some point I'll check the map sector of a really big file and see what it looks like. In theory it would have to be stored as separate chunks of 16MB, being the maximum number of sectors (&FFFF) each map chain can hold) even if they were all contiguous.
Image


Return to “software: other”

Who is online

Users browsing this forum: No registered users and 8 guests