Just an idea about 'file systems'

[dufrp@oricom.ca]

Well, I am thinking since some hours now and I feel the need to put my 
thoughts on "paper" and exchange this ideas with others. I have the
feeling of rediscovering the wheel however. I suppose that this only
some form of persistent, distrubted system. 
  Well I was first thinking about how not enough easy it is to use 
existing code to do better. Of how DLL help to do this. And was asking
myself why allocating memory from RAM is so different of allocating 
memory from a floppy disk.
  Why not have every bytes in the system (RAM or on Floppy or Hard Disk)
have an address.
  I have thought that 
    -1k is 2**10 bytes
    -1Meg is 1k * 1k = 2**10 * 2**10 = 2**20
    -1Gig is 1Meg * 1k = 2**20 * 2**10 = 2**30
    So with 32bits I can address 2**2 * 2**30 = 4 Gigabytes
 It would be Ok for most systems today, at least enough to hold a hard
 disk and the RAM. But before year 2000 12Gb CD-ROM is expected to get out.
 So why not give a 64bits address. This give 4 Gig * 4 Gig = 16 "what?" bytes.
 I don't know how this is called but it looks enough to hold every bytes on
 this planet. (Not so sure.) I don't like the idea of letting the CPU taking
 care of this virtual memory. First it would not accept more than 32 bits.
 But also because it would not keep tracks of what is allocated and what is
 not. This seems to be a software task in my opinion. 
 
  Imagine how fun it would be to make a call to the operating system asking
it to move 300 bytes from 0x3000 to 0x1000000000000000 and then your bytes
would be unallocated from ram memory and 300 bytes would be allocated on
your hard disk and written on it. Or more simply move 'myprogram' to 'HD'.
Date: Sun, 25 May 1997 01:32:32 -0400
Message-Id: <05323204810831@oricom.ca>

  This would means that the OS have a table which told him the starting
address and ending address of memory (like RAM 0-16Megs), Hard Disk (like
16Megs-2016Megs) , Floppy A: (2016Mg-2018Meg), etc... Since the way to 
access Hard Disk is not the same as the way to access RAM we
should add to each entry of this table a physical address of a routine
being able to read and write addresses between low and hi. In the example
of the preceding paragraphs, you could have found that 0x1000000000000000
was in the HD range and call the associated routine to physically make the
transfer of the 300 bytes from 0x3000 to the Hard Disk. Why not have one
of the entry be a remote hard disk? The associated routine
would call the network card to write or read addresses in this range. 

  This table should be able to remember what memory have been allocated
for each entry of this table. E.g. we have supposed before that HD could
be allocated addresses between (16Megs-2016Megs). We could add that from
(16Megs to 46Megs) this will be Programming tools. From (46Megs to 66Megs
will be telecommunications tools). So we should have a table that looks like:

Allocation
==========
No_Allocation (32 bits)
-------------
Begin_Address (64 bits)
Ending_Address (64 bits)
Father_Allocation_Number  (No_Allocation=32bits)
Physical_routine_address_to_make_IO_exchange_with_a_No_Allocation_in_Ram (32b)

  So allocating 300 bytes from RAM would means to check the highest already 
allocated address in all childs of the RAM node, and adding a 300 bytes
long range inside a new child of RAM. But if after that, you want to make
one of the previously allocated child bigger, you have to make some kind of
defragmentation. But only inside the childs of RAM (in this case quite big).
Making the need to be bigger allocation with the higher address range so that
you can make it bigger (that is if there is enough place in the RAM range).

  One of the Allocation could contains a table giving more information
about all Allocations. Like a name, owner, access rights, etc. The idea
is to make some kind of 'File System' but very flexible. This should give
a good starting dot to make hierarchical structures like menus, category-
subcategories etc. What would be still missing is a good messaging system.

  I suppose it looks confusing, but I think you have what it needs to get
the picture. Like I said I'm not sure at all this is a new idea. But this
is at least a new way of seeing OSes for me.

---Paul Dufresne