ext2-3 and FAT12-16-32

[Jeko]

I must write drivers for the most used filesystem. I think they are ext2-3 and fat32... (also ntfs and reiserfs, but they are more difficult to implement)

However I've two little questions:
1) ext2 is a special case of ext3? That is, if I write a driver for ext3, it will support also ext2?
2) the same for fat12, fat16 and fat32.

Are FAT and EXT filesystems difficult to implement?

P.S.: Do you know any other most used filesystems? In my computer I use only FAT32 for the data harddisk (I used FAT32 because when I formatted the harddisk, linux didn't supported NTFS), NTFS for the Windows XP partition and ReiserFS for the Linux partition (Ubuntu distribution).

[bewing]

FAT32 includes the concept of "clusters", which 12 and 16 do not. But the code for each of them is very close, so you can write one, and then make minor changes to create the other two.

The next major one you didn't mention is going to be various flavors of ISO9660. Then UFS, I think.

And the problem isn't writing the drivers for the FSes. It's creating a really good VFS interface. That'll takle you much longer than just cranking out a few drivers.

[quok]

The next major one you didn't mention is going to be various flavors of ISO9660. Then UFS, I think.

I think you mean UDF, if you're talking about the filesystem used on DVDs. UFS is a bit different, although support for UFS/FFS with soft updates would be a nice idea. I think I'll have to add that one to my TODO list. Then I can read/write filesystems created by the BSDs.

[Troy Martin]

The next major one you didn't mention is going to be various flavors of ISO9660. Then UFS, I think.

I think you mean UDF, if you're talking about the filesystem used on DVDs. UFS is a bit different, although support for UFS/FFS with soft updates would be a nice idea. I think I'll have to add that one to my TODO list. Then I can read/write filesystems created by the BSDs.

Yeah, Unix File System isn't really useful unless you're working on a BSD clone IMHO.

I'd start with a FAT12 and 16 driver, then an ext2 driver. Journaling won't be really needed until your OS is really big!

FAT32 includes the concept of "clusters", which 12 and 16 do not.

No, 12 and 16 have clusters. Wikipedia it.

[AJ]

...That is, if I write a driver for ext3, it will support also ext2?
...the same for fat12, fat16 and fat32.

It is relatively easy to write a single FAT driver that will support both FAT16 and FAT12. FAT32 has more differences as already pointed out (for example, the Root directories in FAT12 and 16 are in a special known location whereas this is more dynamic in FAT32). However, they are still similar enough that you if you design your FAT driver interface carefully enough, you can add FAT32 support later (without too many conditionals).

Cheers,
Adam

[Jeko]

And the problem isn't writing the drivers for the FSes. It's creating a really good VFS interface. That'll takle you much longer than just cranking out a few drivers.

I've yet developed a Virtual File System. I think it's a good interface... I've only few doubts on it...

However thank you for all the answers...

ext3 is ext2 with journaling? So can an ext2 driver read an ext3 partition?

[Stevo14]

It is relatively easy to write a single FAT driver that will support both FAT16 and FAT12. FAT32 has more differences as already pointed out (for example, the Root directories in FAT12 and 16 are in a special known location whereas this is more dynamic in FAT32). However, they are still similar enough that you if you design your FAT driver interface carefully enough, you can add FAT32 support later (without too many conditionals).

I actually wrote a fat32 driver first and added support for fat12 later (I still have yet to support fat16). Either way, the same idea holds: write a single fat driver for fat12, fat16, and fat32.

[Jeko]

This is the mount function for ext2 with my VFS:

Code: Select all

int Ext2Mount(fs_node_t *where, fs_node_t *dest)
{
	ext2_t *ext2 = (ext2_t*)kmalloc(sizeof(ext2_t));

	if(IoReadSync(dest, 1024, &ext2->super_block, sizeof(ext2_super_block_t)) != sizeof(ext2_super_block_t))
	{
		kfree(ext2);
		return -1;
	}

	if(ext2->super_block.s_magic != 0xef53)
	{
		kfree(ext2);
		return -1;
	}

	ext2->block_size = 1024 << ext2->super_block.s_log_block_size;

	ext2->num_groups = ext2->super_block.s_blocks_count / ext2->super_block.s_blocks_per_group;

	size = sizeof(ext2_group_desc_t) * ext2->num_groups;
	size = (size + ext2->block_size - 1) & -ext2->block_size;
	ext2->groups = kmalloc(size);

    if(IoReadSync(dest, 2 * ext2->block_size, ext2->groups, size) != size)
    {
        kfree(ext2->groups);
		kfree(ext2);
        return -1;
    }

	where->fs_data = ext2;

	return ESUCCESS;
}

It's enough simple!

However, if ext3 is ext2 with journalling (is it?), this function will work also for ext3!

[thepowersgang]

Ext 3 is just Ext2 with journaling added to it, and can be quite safely read by any ext2 driver. The only thing to watch out for is if the journal wasn't written to disk when it was mounted last as the Ext2 driver wouldn't pick that up.

[Jeko]

I'm writing drivers for the filesystems, but it's a long task, and I want to focus on the kernel...

So I need source code of other working filesystem drivers to adapt the code on my system API.
Where can I find good filesystem drivers?

[Combuster]

Where can I find good filesystem drivers?

http://www.kernel.org ?

[Troy Martin]

Where can I find good filesystem drivers?

http://www.kernel.org ?

Hehe.

Actually, I would seriously refer to the linux kernel archives (they can get big though) if you're working in C/C++.

[Karatorian]

If you're looking for drivers that can be used out of the box and are cleanly insulated from rest of your OS, you might want to look into the Utah OSkit. It's stated goal is to allow an OS experimentor to impliment the stuff they're interested in, while not having to deal with stuff that they don't want to (or don't want to yet).

Years ago when I first got involved in OS dev, I played around with it a bit and it seemed to work pretty well. As I recall the build enviroment was a bit hairy, but they may have improved it since then. It's fairly modular and has cleanly documented deps so that you can use the parts you need without having to use the parts you don't. Give it a try.

[Solar]

As for the ext2 / ext3 thing, as I can speak from personal (user, not developer) experience:

The on-disk layout is the same for ext2 and ext3. Any ext2 driver can read an ext3 partition.

However, as thepowersgang correctly pointed out, while the partition is mounted under ext3, there is additional data present which cannot be interpreted by the ext2 driver.

I have a multiboot system (Windows / Linux), with a shared data partition formated as ext3, accessed by Windows through an ext2 driver. There are two ways to f*** this up:

• having Windows hibernate (instead of shut down), and booting into Linux next time. Windows hasn't written its buffers yet, and if you modify the file structure in Linux Windows will become very confused next time you boot.
• having Linux crash (i.e. not unmounting the ext3 partition correctly) and booting Windows next time. There's additional data on the disk the ext2 driver cannot interpret. A good driver (like mine) stubbornly refuses to mount the partition at all untill it's been cleanly unmounted.

If you keep those traps in mind, yes, ext3 is a superset of ext2 that is compatible with ext2-only drivers (if cleanly unmounted).