Huh, so many posts
@Ethin: true that EFI uses that, so you have to implement it anyway; however I don't think that's make a good root fs for your OS. But definitely a good and easy start. I was also messing around with LEAN, if there's a need I can add support for generating LEAN partitions on-the-fly from directories.
@nullplan: if the patent expires, that's cool
Yes it only involves MICROSOF~1 names. Unfortunately the other problems still exists. Some of those were sorted out in exFAT, but not all.
@Octocontrabass: by "not well specified" I mean there's no "FATEntrySize" field in the BPB. Different tools implement FAT size differently, not all checks the total number of clusters, rather look for the magic bytes "FAT12", "FAT16" and at a different location, "FAT32". MSDN recommends the former, but I'd argue that the latter is a much much better solution, since it is perfectly viable to create a FAT16 with 2048 clusters for example or FAT32 with 4096 clusters. I can't recall it right now which one is which, but mtools and mkfs.vfat uses different approach to identify the size of clusters, that's for sure, I've spent a day with debugging because of it...
@Korona: you're perfectly correct. But for a beginner, specially for the first fs, I'd rather choose something simple. I'd go for FAT (because of UEFI and file interchange) and ext2 for my root (because of access rights). Both are easy to implement and having at least two file systems builds the bed for a VFS. One could run into trouble later if they tie their kernel to one fs at the beginning.
@nexos: ntfs is somewhat documented, but it is an extremely complicated file system. You'll spend months to get it right. The
ntfs3g fuse driver is your best chance to figure out how things should be done the ntfs way. It is stable, and compatible with the undocumented parts too.
@iansjack: what other OS supports matter only when you want to exchange files. UEFI is an exception, because you should be able to interface with it, but you can still boot without implementing FAT (using EFISimpleFileSystem protocol). Otherwise doesn't really matter, I agree that you should focus on the features your kernel needs.
I haven't looked into APFS yet, but I have more than a decade of maintainer experience with ZFS under Solaris, and I've read its spec from top to bottom several times. Extremely complicated, and let me tell you, it sucks big time to use. Moreover, I seriously doubt you can implement that in a hobby OS. Just think about that for Sun it took 4 years to develop (and Solaris wasn't able to boot from it at that point) with a large dedicated team. And look at those poor FreeBSD guys how much they suck to port OpenZFS (they are not rewriting it, just porting it) for more than 7 years now and still not complete and has serious flaws.
FYI: unlike the name suggest, ZFS is actually not a file system. It is a complete volume and storage management solution totally incompatible with any other classic Windows/UNIX paradigms, which Sun developed to force Veritas out of its markets because that two company had some differences. It's like implementing RaiserFS+LVM+software RAID0,1,5 all at once as your first fs.
Cheers,
bzt