On Fri, 31 Mar 2000, Paul Barton-Davis wrote:
>Daniel Phillips suggested to me privately a month or two back that
>there might some general utility in a "raw" filesystem that created a
>single file in a partition, allowed no index, inodes, directories,
>extension, truncation etc. This would be useful for applications that
>need to control disk seeking (such as high end audio applications).
>
>It seems to me that this is rather similar to the idea behind Stephen
>Tweedie's raw i/o stuff. The primary difference would seem to be (and
>I'm guessing here) that with raw i/o, you just do:
>
> % fdisk /dev/foo
>
> . <create partition /dev/fooc>
> .
> .
> % <app using /dev/fooc>
>
> open ("/dev/fooc", ...)
>
>versus:
>
> % fdisk /dev/foo
> % mkrawfs /dev/fooc
> % mount /dev/fooc /somewhere
> % ls /somewhere
> the_file
> % <app using /dev/fooc>
>
> open ("/somewhere/the_file", ...)
>
>If so, then raw i/o would seem a lot easier to use.
>
>However, an additional aspect of my model of the "rawfs" is that you
>could do this:
>
> % mkrawfs -o files=4 /dev/fooc
>
>to create the partition with 4 equally sized, adjacent files. There
>would be a standard name for each file, perhaps just "1", "2", etc.
>
>These files would, of course, be non-deletable, non-truncatable,
>non-extensible, etc. They exist only so that you can guarantee
>contiguous (pre-)allocation of disk sectors for each file, and thus
>get predictable seek performance. However, it would allow all regular
>applications to access each file quite normally.
>
>This is something that it seems that raw i/o can't do, because it
>would force the layout of the "filesystem" (i.e. allocation of the
>disk sectors to specific byte streams) up into the application, and
>would prevent other apps (e.g. cat(1)) that did not know the layout of
>the data from reading the individual "files".
>
>It would seem that by starting with the minix fs and ripping out most
>of it, one would end up with a very, very simple fs of some general
>utility. whether or not it should be called "rawfs" or "rsfs" (Really
>Simple File System) is not clear ...
>
>Can I get some feedback on this idea ?
You might look into some VERY old file system structures - The DEC RT-11
file system used a single level directory.
The first file created in the file system recieved by default half of the
largest free space (always contiguous). The next file recieves half of the
remaining...
The number of of files was determined when the filesystem was created -
this determined the number of blocks in the directory. If I remember
right the directory structure was something like:
struct inode {
unsigned long firstblock; /* first block of the file */
unsigned long size; /* number of blocks in the file */
unsigned long length; /* actual length of the file */
unsigned int date;
char name[8];
};
This differs slightly from that used - the length field didn't exist - file
were terminated by a (ctrl-Z) marker for text, binary files always went to
the end of the block.
A deleted file/empty space was represented by a inode entry that had a null
file name. Whenever a file was deleted the directory entry preceeding it would
be checked to see if it too was a deleted entry. If true then the size fields
of the two entries would be combined (more in a moment). Then the directory
entry following it would be checked; again if it is a deleted entry then
its' length added to the first.
After the coalesing is completed, the first directory entry would be rewritten,
and a compacting of the directory array would follow - the next non-deleted file
entry, and all following entries would be copied. This was to minimize directory
search time (it too is contiguous). File entries would be created by expanding
the list (copy down the array) to make an empty entry. This entry would be
assigned the file name, and half the space.
All files on the filesystem were contigeuous, the directory search was O(n) -
a linear search... There usually weren't more than 256 files on the disk, until
they got into large hard disks (10MB...) where about 1024-4096 directory entries
were allocated.
The directory array was essentially
struct inode directory[MAXFILES] =
{{sizeof(struct directory) % blocksize + 1,
SIZEOFDISK,
0,
"" }
};
The superblock as such only contained the number of blocks in the directory,
and the filesystem type. It may even have started the inode list immediately
after that info.
I think such a file system could be extremly usefull - This is nearly ideal
for a floppy (better than a dos disk - less inode data). Good for a
simplified LILO since only the first block of kernel is needed when booting.
Now linux would need more info in the inode - uid, gid, dates, protection mask
Possibly ACL/MAC/capability list...
But the contiguous nature and single level could be usefull. It would definitely
fit in some of the embeded applications (ones that use a flash prom for a disk)
If it were used for booting Linux, then the modules could also be stored in the
same file system - that would allow for a quick load (either dynamic or at boot
time) of modules.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@cats-chateau.net
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:30 EST