Re: Designing Another File System

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

On Maw, 2004-11-30 at 04:32, John Richard Moser wrote:
> I've been interested in file system design for a while, and I think I
> may be able to design one.  Being poor, I would like to patent/sell it
> when done; however, whatever the result, I'd assuredly give a free
> license to implement the resulting file system in GPL2 licensed code 

Several other vendors have followed this kind of dual model - MySQL,
Troll Tech and Sleepycat being three obvious examples.

> - - 64 bit indices indicating the exact physical location on disk of
> Inodes, giving a O(1) seek to the Inode itself

Until you get a bad block 8) or want to find it in memory (which is the
usual case)

> 1)  Can Unix utilities in general deal with 64 bit Inodes?  (Most
> programs I assume won't care; ls -i and df -i might have trouble)

You would have to ask a unix source code licensee. For Linux inodes can
be 64bit on 64bit platforms, although you would undoubtedly found some
oddments that were not resolved.

> 4)  What basic information do I absolutely *need* in my Inodes? (I'm
> thinking {type,atime,dtime,ctime,mtime,posix_dac,meta_data_offset,size,\
  links}

See posix 1003.1 and the Single Unix SPecification. That defines the
behaviour.

> 5)  What basic information do I absolutely *need* in my directory
> entries? (I'm thinking {name,inode})

Ditto 

> 6)  How do I lay out a time field for atime/dtime/ctime/mtime?

Internal issue to the file system.