OSDev.org

Maybe this question was asked a lot of times, but I want to get a opinion if FAT is a good FS for starters, or there is a simpler FS to implement?

FAT is very simple, but limited. Depending on what you want to do, you might want to start with ext2.

Sure, one can implement a simpler or more regular FS than FAT. Or without some features (e.g. directories or some metadata).
But chances are you gonna need to be able to prepare some FS images. Lots of tools can handle FAT, but won't handle something more obscure. With obscure stuff you'll be on the hook for everything, including those tools.

For now I want a simple FS, in order to start reading executable files, after that I can work in add support to other FS. I will try FAT. Thanks

I agree with Alex as to the point of transferring files to and from your disk images. A common file system, such as FAT, will allow other tools and even other operating systems, to transfer files to and from your media. Also, FAT12/16 is a simple file system to learn and will allow you to focus more on other aspects of your project.

However, since we all do this for the enjoyment, what is your intentions? One of my most favorite parts of this subject happens to be file systems. Therefore, I have created a few files systems simply for the enjoyment of doing so. This breaks the rule mentioned by Alex, where I now must have my own tools to transfer files back and forth to the different media devices/image files, but so what. That is the enjoyment of doing this kind of work.

As for the original question, if you are going to implement multiple file systems, I would look at the following, in order of ease to difficult (in my opinion):

-- SFS -- Discussed within this forum numerous times -- http://www.fysnet.net/blog/files/sfs.pdf
-- FAT12/16
-- FAT32
-- exFAT
-- FYSFS -- My first attempt -- http://www.fysnet.net/fysfs.htm
-- LEANFS -- My additions to an already created file system -- http://freedos-32.sourceforge.net/lean/ (New revision: https://www.fysnet.net/leanfs/index.php)
-- ISO 9660 (Juliet/etc)
-- UDF
-- HPFS
-- Minix
-- Ext2/3/4
-- NTFS
-- BTRFS -- https://en.wikipedia.org/wiki/Btrfs
-- Many others

Note that the more difficult to implement, the more features, security, safety, etc., a file system will have. It is all up to you which one(s) you implement and what you do with them.

Ben
- http://www.fysnet.net/osdesign_book_series.htm

There's a guide about how implement FAT32 (besides the wiki article) that you can recomend to me?
And how I can create a HDD image formatted with FAT32 for QEMU?

PipeDevice wrote:There's a guide about how implement FAT32 (besides the wiki article) that you can recomend to me?

The FAT specification is at http://www.fysnet.net/docs/fatgen103.pdf

PipeDevice wrote:And how I can create a HDD image formatted with FAT32 for QEMU?

There are numerous ways, mostly with tools that someone has already created, all depending on your development platform.
-- I use tools that I have made.
-- If you use *nix platforms, search for MTOOLS.
-- Create your own
-- Mount a file (under *nix) as a partition and format it (I think latest Windows platforms allow this too)

Ben
- http://www.fysnet.net/osdesign_book_series.htm

One thing to note when going for FAT, keep in mind that it has no permission system. This can create future challenges if you ever attempt to retrofit your file system management code when moving to somewhat more complex/different file systems.

davidv1992 wrote:One thing to note when going for FAT, keep in mind that it has no permission system. This can create future challenges if you ever attempt to retrofit your file system management code when moving to somewhat more complex/different file systems.

I feel that ext2 is in the same level of "difficulty" in terms of programming than FAT, and ext2 is more useful than the old FAT. Or it isn't?

PipeDevice wrote: Maybe this question was asked a lot of times, but I want to get a opinion if FAT is a good FS for starters, or there is a simpler FS to implement?

In my opinion, FAT is a good option for starting.

One thing to note when going for FAT, keep in mind that it has no permission system. This can create future challenges if you ever attempt to retrofit your file system management code when moving to somewhat more complex/different file systems.

the poster asked about starting point, "security" subsystem is out of concern at that point. permissions anyway are specified differently on different FSs, so it's twofold - FS independent security subsystem of the OS and particular permission system of each FS in question. FAT won't do any challenges to this scheme, since its lack of permissions may be treated easily - "implied" or "inferred" access rights for example "anyone has access" for removable storages or "none has" - for UEFI ESP. finally, one can add his/her own addition atop of FAT that will bring permission system there, still retaining compatibility with the specification and thus - interoperability. holding permissions info in $SOME_HIDDEN_AND_SCARY_NAMED_FILE$ in each directory for example.

I feel that ext2 is in the same level of "difficulty" in terms of programming than FAT, and ext2 is more useful than the old FAT. Or it isn't?

It isn't more useful. it's just old linux cr4p, nobody else cares about. supporting FAT first, gives you advantage of supporting all kinds of removable media, you and your users would be happy to try on your OS - USB flash sticks, SD cards, for which FAT is standard defined FS, etc. This is really helpful, useful and fun. Also, UEFI ESP is FAT, by the specification, again, advantage - you can access that and update efiyourfolderyourloader.efi and friends from the OS session. and now, what would you get with ext2? even linux doesn't use that.
Of course, as your OS advances, you will want to either invent your own fancy FS or choose some more capable one as a "boot" FS for the OS - FS on which you want your OS would be installed. with this regard, I like most FSs made in 90ths - NTFS, JFS2, XFS, BFS. powerful, but without that horrid bloat and needless attempts to be a food processor.

I think you are wrong about implementing ext2, which is a much more capable filesystem than FAT. It is a very good first step towards ext3 and ext4, and it shares many design features with other more capable filesystems. FAT is an anomaly that is nothing like most other modern filesystems. Ext2 is well documented and the level of difficulty is no more than implementing other parts of the operating system.

FAT may be easy, but it is only a stepping stone. Akin to playing with building blocks rather than building something useful with real bricks. Sure Linux doesn't use ext2 any longer; you may have noticed that it doesn't use FAT either. No modern OS uses FAT, or anything remotely related to it, as the primary filesystem; several use filesystems closely related to ext2.

zaval wrote:supporting FAT first, gives you advantage of supporting all kinds of removable media, you and your users would be happy to try on your OS - USB flash sticks, SD cards, for which FAT is standard defined FS, etc.

You mean exFAT, which is not the same thing as FAT/FAT32.

zaval wrote:Also, UEFI ESP is FAT, by the specification, again, advantage...

You mean the filesystem based on FAT, the specification of which is part of the UEFI specs and independent of the original FAT specs?

I agree that ext2 is a bit outdated (but supported by both Linux and Windows -- the latter through third-party drivers). But at least play it fair when making the comparisons.

Anyway, if you do the architecture right, once you got the abstraction layers done adding more filesystem drivers should be pretty easy. Hopefully so easy that aspiring users of your OS could do it themselves.

iansjack wrote: I think you are wrong about implementing ext2, which is a much more capable filesystem than FAT. It is a very good first step towards ext3 and ext4, and it shares many design features with other more capable filesystems. FAT is an anomaly that is nothing like most other modern filesystems. Ext2 is well documented and the level of difficulty is no more than implementing other parts of the operating system.

FAT may be easy, but it is only a stepping stone. Akin to playing with building blocks rather than building something useful with real bricks. Sure Linux doesn't use ext2 any longer; you may have noticed that it doesn't use FAT either. No modern OS uses FAT, or anything remotely related to it, as the primary filesystem; several use filesystems closely related to ext2.

I thought I wrote it clearly, looks like I didn't - FAT is more useful to have as a first implemented FS for an osdev enthusiast, because it is still widely used as a FS for removable storage devices. so having it implemented, one gets 2 in 1 - experience with FSs and also his/her work will be really useful, and not just lying dormant, since ext2 is a nearly extinct linux legacy. we all have USB sticks, our imaginary users have them. and all of them are formatted as FAT disks. imagine, our poster finishes his/her FAT driver and what an excitement it will be for him/her to insert a USB stick and list its contents from within his/her own OS. (of course, it will happen only after he/she is done with EHCI/UHCI/OHCI/XHCI stuff, but it's another story, ext2 won't help with anyway). his/her users also would be happy to have that when playing with his/her OS. with FAT support, his/her OS will be more functional, because no matter whether you like it or not, FAT is still (and will be) widely used and embedded into several standards, I said that already. there will be no such an expereince with ext2, certainly. I thought it's so obvious. and I specifically emphasized about the "primary" FS:

zaval wrote: Of course, as your OS advances, you will want to either invent your own fancy FS or choose some more capable one as a "boot" FS for the OS - FS on which you want your OS would be installed.

So I don't really understand, why this argument about "primary" FS from you. ext2 btw is as bad for the primary FS as FAT is, but FAT is good for small removable storages and is used there, ext2 isn't.

also, I disagree with the statement about FAT being a "stepping stone" not giving one to "build" something. it's simple enough for a starter, still it leaves room for challenges - the already mentioned embedding your own extensions for bringing permission control for example. or optimizations. think of it - the FS scales poorly with modern large volume sizes, it was not designed for such, so thinking out some "in memory" optimizing things to the FAT "engine" would be both useful and learning. for example speeding up directory lookup by generating in memory a more scalable (than just a list) structure for directories. or sophisticated cluster allocator (free space handling). and again as a FS, FAT is just yet another FS for the remaining OS components, it's totally untrue to think, that choosing FAT vs. ext2 would prevent one from making, say cache manager or VFS or whatever good.

Solar wrote: You mean exFAT, which is not the same thing as FAT/FAT32.

No, I meant the whole FAT family. exFAT is standard for only SDXC cards. but anyway, exFAT is being released by MS for implementations. for linux already. there are some uncertainties about others, but I believe, it will be cleared up eventually.

Solar wrote: You mean the filesystem based on FAT, the specification of which is part of the UEFI specs and independent of the original FAT specs?

Can you tell what the real differences between those are and are there? The relevant passage in the spec basically tells us, that it's a fixed version of FAT32 (1.03) with no additions in future. for compatibility. I guess, FAT by itself is fixed for a long time. so, the only difference is another OSType value in the partition scheme, which is outside of a FAT driver scope anyway. The whole relevant quote:

12.3 File System Format
The file system supported by the Extensible Firmware Interface is based on the FAT file system. EFI defines a specific version of FAT that is explicitly documented and testable. Conformance to the EFI specification and its associate reference documents is the only definition of FAT that needs to be implemented to support EFI. To differentiate the EFI file system from pure FAT, a new partition file system type has been defined.
EFI encompasses the use of FAT32 for a system partition, and FAT12 or FAT16 for removable media. The FAT32 system partition is identified by an OSType value other than that used to identify previous versions of FAT. This unique partition type distinguishes an EFI defined file system from a normal FAT file system. The file system supported by EFI includes support for long file names.
The definition of the EFI file system will be maintained by specification and will not evolve over time to deal with errata or variant interpretations in OS file system drivers or file system utilities. Future enhancements and compatibility enhancements to FAT will not be automatically included in EFI file systems. The EFI file system is a target that is fixed by the EFI specification, and other specifications explicitly referenced by the EFI specification.
For more information about the EFI file system and file image format, visit the web site from which this document was obtained.

Try to follow their logic, expressed this dimly in the quote, and you'll find*, that their FAT is not "independent" from the original one, it's fixed at the chosen version. they don't specify FAT, there is no FAT doc from UEFI, they reference MS site.

* - the last sentence in the quote, in fact suggests you to visit this page, intended to deal with broken external links (ironically, the FAT link is broken now ), - https://uefi.org/uefi (exactly where you are directed to by the "References" appendix, in the 2.5+ version). there, you see the link to the MS FAT spec. also in the "References" section of both 2.4 and 2.7 explicitly stated the version of FAT32 - 1.03.

zaval wrote:[...] since ext2 is a nearly extinct linux legacy[...]

ext4 is just ext2 with some options. If I counted correctly, you only need to implement five incompatible options and you can already read an ext4 image. Another six read-only options and you can write to it. Another four compatible options to get improved performance. And ext4 is the default FS of most Linux distributions at this time.

So no, ext2 is about as extinct as FAT12.

zaval wrote:No, I meant the whole FAT family.

Oh, OK. I misunderstood you there.

Then please don't compare "the whole FAT family" with ext2, but with "the whole extfs family", i.e. ext2, ext3, ext4.

Yes, FAT support will eventually be beneficial for removable device support. As a main FS for the OS partition itself? extfs, hands down.