Messages in this thread | | | From | Bernd Eckenfels <> | Subject | Re: Designing Another File System | Date | Tue, 30 Nov 2004 08:16:53 +0100 |
| |
In article <41ABF7C5.5070609@comcast.net> you wrote: > when done; however, whatever the result, I'd assuredly give a free > license to implement the resulting file system in GPL2 licensed code (if > you're not making money off it, I'm not making money off it).
You can't restrict the GPL.
> I've examined briefly the overall concepts which go into several file > systems and pooled them together to create my basic requirements. In > these include things such as:
It is not a good idea to publish your ideas if you want to patent them.
> - - localization of Inodes and related meta-data to prevent disk thrashing
Why do you asume inodes?
> - - 64 bit indices indicating the exact physical location on disk of > Inodes, giving a O(1) seek to the Inode itself
How is that different from Logical Block Numbers with a fixed cluster factor? (besides it wastes more bits)
> - - A design based around preventing information leaking by guaranteed > secure erasure of data (insofar that the journal even will finish wiping > out data when replaying a transaction)
Hopefully optional.
> 2) Are there any other security concerns aside from information leaking > (deleted data being left over on disk, which may pop up in incompletely > written files)?
IT-Security is about availability and reliability also.
> 3) What basic information do I absolutely *need* in my super block?
How should WE know? (For mount you might want to have versioning and uuids)
> 5) What basic information do I absolutely *need* in my directory > entries? (I'm thinking {name,inode})
Think about optimizations like NTFS, where you can sort directories by attributes and store often used attribtes in the dir, so you dont need a inode dereference (MFT lookup in case of ntfs)
> Directories will have to be some sort of on disk BsomethingTree. . . B*, > B+, something. I have no idea how to implement this :D I'll assume I > treat the directory data as a logically contiguous file (yes I'm gonna > store directory data just like file data). I could use a string hash of > the Directory Entry name with disambiguation at the end, except my > options here seem limited:
Dont forget to optimize directories for all 4: insertion/deletion/lookup and traversal.
> I guess the second would be better? I can't locate any directories on > my drive with >2000 entries *shrug*. The end key is just the entry > {name,inode} pair.
Do you want to run old style NNTP Servers?
> Any ideas?
In fact I miss a bit a new idea, so what makes your FS better, why should anyone use a non-open source implementation if it does not provide anything new?
Greetings Bernd - 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/
| |