OSDev.org

I know this isn't an OS design... but I figured this could go here..

I have been thinking recently about how incompatible filesystems were..

I was thinking about making a file system supporting nearly nothing, but the way it is designed, being very extensible.

Base support is:
only up to 4G size files
Unix permissions(including mode, uid, gid)
directories
256 character names(ascii)


My problem with the design is the index. If I have it include an index(or FAT or whatever) then it makes it less extensible, and more complicated to implement. But without an index it would be awful slow.

By not having an index, that would be the first sector of the data section would be the first file. at the beginning of the sector is things like how big the file is, if its a file, directory, or special, mode/gid/uid stuff... etc, and the next file would be after that block for that file. So, navigating among a lot of small files would be horribly slow... plus directories wouldn't work well like that.

Another(better) idea is to have each directory(include /) contain a separate index.

anyway though..
the key point is that its so simple. If a index node were marked somethign other than directory or file, that would mean it was special. Special nodes are where extensions are used. Extensions that could be a better index for searching, or a compressed/encrypted file, or just about anytihng. But another OS could implement this Filesystem and still read most of the disk, even with 3rd party extensions used on it. If there are compressed files or something, then of course the other OS will not be able to read those files, but it will be able to read the rest of it because the standard calls for all the extensions to conform so that they can be ignored...

Does anyone see any flaw in this idea?

Making a filesystem generic in the way you are suggesting doesn't really make it generic, because the extensions would need to be supported for each OS that uses the filesystem. Extensions like metadata journaling could render large parts of your filesystem unusable to some OSes.

The incompatibility between filesystems is just the result of their different strengths and weaknesses. For example, XFS has superior performance with large files, but falls short when dealing with small files. Ext3 has generally lower performance than most filesystems, but is closely related to ext2 and makes backward and forward conversion simple.

A better idea IMHO than creating a new extensible filesystem would be supporting multiple existing ones, unless they lack features that you require. In that case, just make a completely new filesystem.

This is what I call "secondary battlefield". Like creating a new language, writing a new assembler / compiler, or something like that. Sure, there are things that could be improved in those fields. But they are not necessary to write your own OS, and they are a massive project in their own right, requiring their very own expertise and know-how. You should think twice (or more) about including such a "secondary battlefield" in your OS project, because the ROI (return-on-investment) is questionable.

For most if not all operating systems, supporting existing filesystems is simply more important, because those are what most media is formatted in. Sure, you could add a "portable FS" of your own to the fray, but personally, I would postpone that until after I got ext2, ext3, and FAT32 running. Even then, I'd be more interested in reiserfs3/4, NTFS, XFS and others.

But that might just be me.

Other than that, JohnnyTheDon already made good points.