[Unix-jun72] Anyone working on V1 mkfs?

[Unix-jun72] Anyone working on V1 mkfs?

[Warren Toomey]

We're going to need a filesystem. Is anybody working on tools to make one?
If not, I might start work on a mkfs for V1.

	Warren

[Unix-jun72] Anyone working on V1 mkfs?

[Tim Newsham]

> We're going to need a filesystem. Is anybody working on tools to make one?
> If not, I might start work on a mkfs for V1.

The u0.s srcs have code for writing out some filesystem data when the
kernel is built with the "cold" variable set.  I'm not sure how complete
it is.  It sounds like Brad has had some success getting it to run based
on his earlier emails.

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/

[Unix-jun72] Anyone working on V1 mkfs?

[Brad Parker]

Warren Toomey wrote:
>We're going to need a filesystem. Is anybody working on tools to make one?
>If not, I might start work on a mkfs for V1.

The kernel sources can built with "cold = 1" to build the root file
system on the RF disk.

It almost works now - it writes a bunch of blocks but not the directory
blocks (yet); something is now quite right but I'm pretty sure it can
be worked out.

The hardware bootstrap process is in the man pages - it looks somewhat
rational.  I have not studied it but I think the fun part will be making
a dectape image which has the binaries to be populated.

It all looked possible when I scanned it the other day.

Having said all that, having a working mkfs would be would be very handy
and would make setting up  a boot disk much easier!

-brad

[Unix-jun72] Anyone working on V1 mkfs?

[Warren Toomey]

On Thu, May 01, 2008 at 08:33:35PM -0400, Brad Parker wrote:
> The hardware bootstrap process is in the man pages - it looks somewhat
> rational.  I have not studied it but I think the fun part will be making
> a dectape image which has the binaries to be populated.

I was hoping to have a populated filesystem to start with, because we
should be able to run V1 bin/check using Apout, to check the filesystem.
 
> Having said all that, having a working mkfs would be would be very handy
> and would make setting up  a boot disk much easier!

The V1 manual for filesystem(5) say "Blocks 0 and 1 are collectively known
as the super-block for the device". Can you confirm that block 0 is part
of the super-block, i.e. it's not reserved for bootstrap code? If block 0
is the super-block, it should contain a word (# of bytes in free-map) followed
by lots of 0177 bytes, which are the free-map.

On another note, I thought of taking V6 mkfs.c as a start-point to rewrite
V1 mkfs. I'm trying to work out what f_m and f_n do:

        if(fsys[n] == 'r') {
                if(f == 'k') {
                        f_n = 24;	/* RK, why these numbers? */
                        f_m = 3;
                }
                if(f == 'p') {
                        f_n = 10;	/* RP, why these numbers? */
                        f_m = 4;
                }
        }

Finally, are we going to use RK03 or RK05, as the sizes are different?

Thanks all,
	Warren

[Unix-jun72] Anyone working on V1 mkfs?

[Tim Newsham]

> On another note, I thought of taking V6 mkfs.c as a start-point to rewrite
> V1 mkfs. I'm trying to work out what f_m and f_n do:
>
>        if(fsys[n] == 'r') {
>                if(f == 'k') {
>                        f_n = 24;	/* RK, why these numbers? */
>                        f_m = 3;
>                }
>                if(f == 'p') {
>                        f_n = 10;	/* RP, why these numbers? */
>                        f_m = 4;
>                }
>        }

Looks like they stagger the insertion of blocks onto the free list
so that they're not adjacent.  It first builds a table in adr[] of
the stagger offsets, then it frees blocks from the top linearly
until it hits a round number, then it allocates as many staggered
blocks as it can until finally returning to allocating the bottom
f_n blocks in a linear fashion again.  For example if f_n is 10 and
f_m is 4, and igh is 100 and low is 20 you puts blocks on the
list in this order:
     0,    - always zero first
     100   - linear at top
     99, 95, 91, 97, 93, 98, 94, 90, 96, 92, ...
     33, 38, 34, 30, 36, 32
     29, 28, 27, ... 22, 21, 20    -- linear at the bottom

as to why they chose these particular constants for these disks,
I can only guess that they figured having blocks roughly four
apart made for good performance due to read and seek latencies?

> Finally, are we going to use RK03 or RK05, as the sizes are different?

The sources mention "rk03" several times and give 4872 decimal as
the maximum block number allowed (and also rf0 with 1024 as maximum
block number).

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/

[Unix-jun72] Anyone working on V1 mkfs?

[Warren Toomey]

On Fri, May 02, 2008 at 10:58:08AM +1000, Warren Toomey wrote:
> On another note, I thought of taking V6 mkfs.c as a start-point to rewrite
> V1 mkfs.

I gave up and decided to write mkfs from scratch :-)

I'm a bit baffled on the i-node map and list. The V1 filesystem(5) manual says:

	I-numbers below 41 (base 10) are reserved for special files, and
	are never allocated; the first bit in the i-node free map refers
	to i-number 41. Therefore the byte number in the i-node map for
	i-node i is (i-41)/8 and offset (i-41)%8 bits from the right...

	I-numbers begin at 1, and the storage for i-nodes begins at block 2.
	Also, i-nodes are 32 bytes long, so 16 of them fit into a block.
	Therefore, i-node i is located in block (i+31)/16 of the file system,
	and begins 32*((i+31)%16) from its start.

	I-node 41 (base 10) is reserved for the root directory.

Now, I am assuming that this means:

  a) the i-mode bitmap is missing bits 0 to 40, but
  b) the actual i-nodes 0 to 40 do exist, and
  c) the system can still "read i-node 7", even if it can't allocate i-node 7.

Following the manual, the root directory i-node is number 41, so its
bit in the bitmap is (41-41)/8==0, offset (41-41)%8== bit 0. But the
actual i-node used is still i-node 41, so that is on block (41+31)/16==block4,
offset 256.

Let me know if that sounds right, or if I'm off-base somewhere.

Thanks,
	Warren

[Unix-jun72] Anyone working on V1 mkfs?

[Tim Newsham]

>  a) the i-mode bitmap is missing bits 0 to 40, but

    The first bit is for i-number 41, yes.
    if(n >= 41) then to check if i-number n is allocated:
        map[(n-41)/8] & (1 << ((n-41)%8)

    if I read the bit ordering correctly.

>  b) the actual i-nodes 0 to 40 do exist, and

    Almost, there is no i-number 0.  The first one is i-number 1 which
    starts at byte zero of block 2.

       inode-block(n) = (n+31)/16
       inode-offset(n) = 32 * ((n+31)%16)

>  c) the system can still "read i-node 7", even if it can't allocate i-node 7.

    sounds like it.

> Let me know if that sounds right, or if I'm off-base somewhere.

Sounds like you got it, except for the i-numbering starting at 1.

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/

[Unix-jun72] Anyone working on V1 mkfs?

[Tim Newsham]

> I gave up and decided to write mkfs from scratch :-)

I did a little more research on the disks, and added my notes
to the machine.txt file.  Included below.  Looks like we should
be able to craft a tape image with a list of files and use the
cold boot mechanism to initialize the rf0 disk (which has to be
the root fs).  We may still want an mkfs for initializing an
rf03 later.

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

Disks:
    rf0 - 1024 blocks, always mounted, has root and swap.
          last 64 blocks (32kbyte) allocated to swap by u0.s
          u0.s can setup rudimentary fs on this if built with "cold=1"
    rk0 - 4871 blocks


u0.s sets up rf0 as:

    - superblock layout
      - free storage map contains 128 bytes
      - inode map contains 64 bytes

    - allocate top 64 blocks "to unix"  (960..1023)
    - allocate 17 blocks per process (nproc) (688..960 - 16 procs)
    - free blocks 687..34
    - zero out blocks 33..1 for use as inodes
      (and 2nd half of superblock which is unused?)

    - for each special inode i-1 to i-40 initialize it
      - mode 100017 (allocated, read, write, other read, othe write)
      - num links = 1
      - uid = 1 (yup, not root)
      - fill in timestamp info

   - write out premade i-nodes on i-41 .. i-47
     with premade directory data.
     i-41 root (with dev, bin, etc, usr, tmp)
     i-42 dev (with tty, ppt, mem, rf0, rk0, tap0 .. tap7, tty0..tty7, lpr, 
tty8)
     i-43 bin (empty)
     i-44 etc (with init)
     i-45 usr (empty)
     i-46 tmp (empty)
     i-47 init (binary, included in u0.s)
          special version that opens /dev/tap0 and reads files from it,
          creates them, chmods them and chowns them


Tim Newsham
http://www.thenewsh.com/~newsham/

[Unix-jun72] Anyone working on V1 mkfs?

[Warren Toomey]

On Thu, May 01, 2008 at 05:21:54PM -1000, Tim Newsham wrote:
> >I gave up and decided to write mkfs from scratch :-)
> 
> I did a little more research on the disks, and added my notes
> to the machine.txt file.  Included below.  Looks like we should
> be able to craft a tape image with a list of files and use the
> cold boot mechanism to initialize the rf0 disk (which has to be
> the root fs).  We may still want an mkfs for initializing an
> rf03 later.

Thanks for the notes Tim. In mkfs, I'm creating the free list, the inodes
and inode list, and the rootdir, along with adding entries to a dir. Next
up, adding files to the image. It will probably be testable in a few days.

	Warren