Suitable file system for early OS development

[OSwhatever]

I need a very simple file system for ramdisk images to begin with. The most obvious choice that you might think about would be VFAT, but since my development system is not x86 and I have no compatibility requirements at this stage which enables me to choose any file system I want. VFAT despite it is simple is not that simple in reality. Long file name support require non-trivial conversion between the my OS native utf8 strings and Windows type utf-16 strings including locales. Also directory entry garbage collection is something you have to deal with (Microsoft implementation doesn't even do this and just extend the cluster chain instead). Dealing with the extra 8.3 directory entry and so on. I have now the option to go for even simpler file systems with better design.

According to Osdev there is SFS which looks nice. However, I have to limit my OS developing effort to not designing and implementing file system otherwise the project grows too large for me. This means I would preferably need source code + image tool of the shelf. I did not find any source for SFS.

Basically, do you know the convenient source for a good simple file system that enables me to get a file system implementation + image quickly in my system.

[NickJohnson]

If you only need a readonly image, using a tape archive (tar) might be a good choice. That's what I use for the bootup ramdisk on my system, and it works fine. Since its headers are textual, you don't have to pay attention to endianness (which I suppose could be a problem for you since you're not on x86.) It's also very easy to make images, since every *nix system has a standard tar implementation. You can implement a purely in-memory filesystem (like Linux's tmpfs) over that to make a read/write ramdisk.

As far as real filesystems go, it still might be a good idea to implement VFAT, because it's so common and the tools are readily available for making images. You could cut some corners for the initial implementation, like limiting all text to ASCII (which should be fine for most cases anyway,) or ignoring garbage collection and long file support, so that you can make sure the more important stuff is working first.

[Combuster]

Basically, do you know the convenient source for a good simple file system

Asking for code wasn't quite the topic title.

Problem here is that the logic to actually read a filesystem is very dependent on your actual FS interface and can therefore not just simply be stolen from somewhere.

In fact, in the case of SFS/FAT it's probably faster to just implement the few lines you need unless you already know where to look. And it's more educational as well.

[turdus]

I use the same fs to boot that used later. The only difference is that I've implemented a very small, read-only "driver" in the loader, and a fully featured one in kernel. It's harder to start, but pay out very well later on, and I do not need special tools to create an image.

If you want to use a simple fs, tar could be a good one as mentioned before, but if I were you I would also pay attention to cpio, that's what most linux distro use. It has a smaller header with ascii octal numbers (endianess independent). The tricky part is the padding after each file, otherwise they're quite the same.

[OSwhatever]

I use the same fs to boot that used later. The only difference is that I've implemented a very small, read-only "driver" in the loader, and a fully featured one in kernel. It's harder to start, but pay out very well later on, and I do not need special tools to create an image.

If you want to use a simple fs, tar could be a good one as mentioned before, but if I were you I would also pay attention to cpio, that's what most linux distro use. It has a smaller header with ascii octal numbers (endianess independent). The tricky part is the padding after each file, otherwise they're quite the same.

Which fs are you using, own design or known fs?

The fs I'm looking for should work for both read and write access.

[Combuster]

My bootloader uses FAT because that's the filesystem it boots from. Using write-once filesystems like most ramdisk formats won't be the best choices if you need write access, because that's not what they were designed for.

I guess Turdus uses FAT (maybe ext2) given the description.

[OSwhatever]

I found this file system

http://freedos-32.sourceforge.net/lean/

Which goal is to be simple. Source code available and also tools for image creation. It seems to be limited to 512 sector sizes only which can be a little bit inconvenient but that can be solved.

[Combuster]

It's less simple than FAT, let alone SFS. It is therefore a failure as the design goals were not met.