OSDev.org

A while back (two years ago) I wrote a spec for a simple yet decent Filesystem. It does lack some fetures like journal, but there is room for future updates, I hope to make a ufs2 adding these features, maybe not even a full update and just a patch idk, but there are resureved areas in the headers for extension. I will include a full spec download.

I wrote this to try to make a simple filesystem with good functionality for a root fileystem.

License: MIT

Github: https://github.com/Xeno333/ufs
TOR: http://xeno3gf2oulcjef7y5gawia6waunuhku ... 0_Spec.pdf

Notice: Octocontrabass's idea has been taken into consideration, this is an updated spec adding the VBR.

You might want to consider a different name.

Your filesystem is not compatible with legacy BIOS boot. Any boot disk using your filesystem will need a separate boot partition.

Your GPT GUID is not unique. (Do you need to define one? GPT GUIDs are usually defined by the operating system using the partition, not the filesystem.)

Octocontrabass wrote:You might want to consider a different name.

Your filesystem is not compatible with legacy BIOS boot. Any boot disk using your filesystem will need a separate boot partition.

Your GPT GUID is not unique. (Do you need to define one? GPT GUIDs are usually defined by the operating system using the partition, not the filesystem.)

GPT uses a filesystem type GUID, this is unified based on the FS type (e.g.The GUID for a partition formatted with the FAT32 filesystem is: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) This is NOT the partition GUID

It has no problem with BIOS, it only would need a dedicated boot partition for UEFI

Name wise I might need to think about it lol, although I think I will stick with it( IBM has a HFS that has nothing to do with Apples HFS.) I think i might specify to use lower case "ufs" and it will follow the ext naming system so ufs2/3/4/5/6...

Xeno wrote:It has no problem with BIOS,

It most certainly does. The first sector of the partition does not start with boot code, so it can't be used to boot.

Octocontrabass wrote:

Xeno wrote:It has no problem with BIOS,

It most certainly does. The first sector of the partition does not start with boot code, so it can't be used to boot.

I dont ever deal with a disk without a partition table so the first sector is always MBR and bootload then the rest is on the partition. I guess your right, when its a disk with no partition table.

As foor booting parition MBR you are right, when not using a bootload designed to boot with this FS

It has a speacel area after the first secotr to be used as a second stage bootloader
but you are right, in part.

My bootloader for my OS(s) work just fine, you simply must use a bootload that suports this FS

Even with a partition table, the MBR loads and jumps to the first sector of the partition. (And there's one BIOS out there that might skip the MBR and go directly to loading the first sector of the active partition...)

I edited my post because I remembered that most bootloaders do that.

You can simply use a bootload that insted loads and jumpes to the resaerved area, as designed, but I do normaly use a boot partition in my testing buit both work

I will take this into consideration though, but I think using a boot partition is most practical anyway

I very well might shift the Filesystem up one sector from the partition, so that the first secot is resurved for bootloader.

I have updated the spec with one minor tweak, to resurve the first sector. And to specify that the UDB is directly after the VBR, as I never really, specified where the UDB was.

Octocontrabass wrote:Even with a partition table, the MBR loads and jumps to the first sector of the partition.

Neither GRUB nor Limine do that in their MBRs as far as I can tell. Both load code from some fixed sector, without consulting the partition table.

That's true, but if you use them to chainload a partition, they still load the first sector of that partition the same way a typical MBR would.

That problem has been resloved

qookie wrote:

Octocontrabass wrote:Even with a partition table, the MBR loads and jumps to the first sector of the partition.

Neither GRUB nor Limine do that in their MBRs as far as I can tell. Both load code from some fixed sector, without consulting the partition table.

The Linux guys apparently have poor understanding of how MBR works, and often doesn't write the correct information into the boot records. Some versions even cannot handle chaining properly. I think it is the Microsoft standard that applies here, and Linux, GRUB and Limine are doing things the wrong way.