Messages in this thread | | | Subject | Re: Designing Another File System | From | Alan Cox <> | Date | Tue, 30 Nov 2004 16:31:10 +0000 |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |