OSDev.org

Just to be clear, I'm referring to SFS as specified on the wiki and not other unrelated simple file systems. Oh and If anyone wants to talk me out of using it then this is your chance!

I am wondering if anyone has used SFS in they're project on a partitioned drive and if so what partition type id they used.

The draft specification is great and although it reserves space for partition information in the super-block and it's clearly envisioned also to be used for hard drives I can't find a recommended partition type id anywhere. If someone or a group already picked a partition type id then it would be foolish for me to pick one myself.

IMO SFS serves as educational material and it can get you started. It comes in handy when used as initramdisk, but for actual storage system, you should eventually drop it due to lack of features.

Answer to your question: according to wikipedia, SFS has no registered id yet.

bluemoon wrote:It comes in handy when used as initramdisk

You've read my mind. Boot floppy and/or boot partition <=32MB. I'm not going to cripple the implementation that it couldn't be used for data transfer between computers. But I don't envision it at the root file system.

bluemoon wrote:Answer to your question: according to wikipedia, SFS has no registered id yet.

Yes I know, but I doubt a partition id choosen for a hobby os would make it on that wikipedia page. That's why I'm asking, if anyone here already picked one for they're project I should use that as the defacto id. Just me being playing nice.

If you are going to use it for a initramdisk, then what does it matter?

kiznit wrote:If you are going to use it for a initramdisk, then what does it matter?

I updated my earlier reply to make it more clear what I had in mind. Sorry I missed your reply while doing that.

Using it as a initramdisk is so far in the future I shouldn't even talk about it. In the near future I want to use it as a separate boot partition.

Hi,

I don't think anyone has given it a partition type ID yet.

If you want to choose one, just pick any ID that's not currently in use and update the wiki page (and maybe do the same for the 16-byte GUID used by the GPT partitioning scheme).


Cheers,

Brendan

Nutterts wrote:Just to be clear, I'm referring to SFS as specified on the wiki and not other unrelated simple file systems. Oh and If anyone wants to talk me out of using it then this is your chance!

Okay, I already asked "seriously?" in the other thread, so I guess I should say something now.

I guess SFS works okay(ish) for read-only use cases where you create the image once and leave it unchanged then (basically like you handle ISO images). It might not perform very well, but it will do the job. You can also add new files to an existing image; resizing (growing) existing files can be done by copying them. You get into trouble as soon as you want real write support, because the space can't be safely reclaimed, so you'll inevitably run into "disk full" errors even if most of the space is unused – your only other option is doing some compaction, which is a quite complex thing and impossible to implement safely (i.e. if your computer crashes in the middle, your file system ends up corrupted).

So if you want write support, SFS isn't really an option; and if you don't want it (yet), ext2 or FAT are almost as simple to implement, have more/better tools, are more useful anyway and the driver can eventually extended with write support. For an initrd, however, I guess I would just pass the kernel a tarball.

For more details on SFS, you may want to read the old thread at http://forum.osdev.org/viewtopic.php?p=201459#p201459

If you ask fdisk, it lists SFS (a different one, but hey why not?) under partition IDs. However if you actually use that, an installed Windows on the same machine refuses to boot
€.02

Kevin wrote: your only other option is doing some compaction, which is a quite complex thing and impossible to implement safely (i.e. if your computer crashes in the middle, your file system ends up corrupted).

Nonsense. The correct and safe way is to copy entire files and leave the original in place, followed by an index update to point to the new location. Much like how defragmenting a FAT filesystem works under the hood by first moving everything to the end of the partition before putting things back in contiguous order.

Kevin wrote:

Nutterts wrote:Oh and If anyone wants to talk me out of using it then this is your chance!

Okay, I already asked "seriously?" in the other thread, so I guess I should say something now.

Yeah, I was thinking of you when I wrote that. I read the old forum posts and it's indeed debatable if it's a simple file system if you want random access in the sense of adding/removing/growing/shrinking files. The complexity is essentially shifted to the chkdsk utility. But in my case I'm not looking at using it as a random access file system.

But I just want something simple that a single sector of code can easily find and grab the required files from. Now I agree I could just use fat12 for floppy and/or fat16 for hard drive. But I don't like the 8+3 file name limitation. Also with SFS the files is in consecutive sectors and with fat I'd have to walk the chain. Which I agree is a bad excuse and not that much harder...but o well. call me lazy.

Ext2 would be a viable alternative but imho it's much more complex. I might have misjudged it, I'll reread the specification today, but it seemed I couldn't fit the code to find and grab files in just 512 bytes. And I want to fully understand something when it use it and I don't have that level of understanding with ext2 yet. But that's both a flaw in me and a design decision, not a flaw in ext2.

As for the just throwing a tarbal at it. Well... I could also just put the config and kernel in sector 2+ without using a file-system.. That'll work. But I wanted something a little bit more elegant and becoming of a hobby OS. Keeping it simple but nicely polished.

Brendan wrote:I don't think anyone has given it a partition type ID yet.

If you want to choose one, just pick any ID that's not currently in use and update the wiki page (and maybe do the same for the 16-byte GUID used by the GPT partitioning scheme).

Guess in the last 10 years nobody really used it. A shame. Some may find it a purely academic filesystem but I kind of feel it has it's own niche uses. Thx, i'll do that, unless I'm brainwashed into using ext2 instead of cource.

Combuster wrote:If you ask fdisk, it lists SFS (a different one, but hey why not?) under partition IDs. However if you actually use that, an installed Windows on the same machine refuses to boot

Mmm, I missed that one. Ty.

Kevin wrote:ext2 or FAT are almost as simple to implement

I just reread the ext2 specs and I'm just wondering how anyone would name ext2 in the same breath with fat and call it simple to implement.

Ext2 is out of the question for now. Fat is to legacy. SFS seems a nice file system to start with. After reading Combusters reply I might have even underestimated it. Not that I don't want to support fat, ext2 and the rest. But... not right now.

Nutterts wrote:Ext2 would be a viable alternative but imho it's much more complex. I might have misjudged it, I'll reread the specification today, but it seemed I couldn't fit the code to find and grab files in just 512 bytes. And I want to fully understand something when it use it and I don't have that level of understanding with ext2 yet. But that's both a flaw in me and a design decision, not a flaw in ext2.

A read-only ext2 driver really isn't that bad. Adding write support is where it becomes a little tricky. But I think you're right that 512 bytes aren't much for proper parsing of ext2.

But see, that's exactly why I argued against beginners writing their own bootloader and that people should either write a good bootloader or none. You've got your own bootloader now, but you didn't do it right, but just implemented something very minimalistic on the side while you really wanted to write a kernel. Now this bootloader is limited to 512 bytes and your choice of file systems is severly limited. A bad bootloader that influences an important aspect of your OS - that's the typical pattern I wanted to warn against.

The proper solution would be (and I already know you won't do this ) to either throw your boot loader away and use e.g. Multiboot, or to stop developing your OS for now and instead work on your bootloader until it's a decent piece of software that doesn't severly limit the OS it loads. And then you can use more than 512 bytes and implement a proper filesystem driver.

Some may find it a purely academic filesystem but I kind of feel it has it's own niche uses. Thx, i'll do that

If you know about the problems and are willing to accept them, that's fine. I wouldn't do it, but it's your OS, after all.

Nutterts wrote:Fat is to legacy.

FAT16 maybe legacy, but you can "upgrade" it all the way to VFAT or FAT32 fairly straightforward and use it on boot partition or usb stick.

bluemoon wrote:

Nutterts wrote:Fat is to legacy.

FAT16 maybe legacy, but you can "upgrade" it all the way to VFAT or FAT32 fairly straightforward and use it on boot partition or usb stick.

That's true. I was mainly referring to the 8+3 file names. Not that I imagine anyone in 2015+ being dragged to court over using long filenames without a license. The legal aspects of VFAT (is it really that different from FAT32?) I'm not well informed about.

I guess I'm just heavily biased, which is kind of weird seeing how often I still use a dos machine.

Kevin wrote:But see, that's exactly why I argued against beginners writing their own bootloader and that people should either write a good bootloader or none.

Anything worth doing is worth doing right. I totally agree with that. I'm also still unsure if what I'm working on is a multi-stage bootloader, a realmode kernel or ??.

The 512byte code is just for loading that real mode kernel. Which is the end of the line when it comes to my vintage computers running real mode servers and programs. But if the cpu is 386+ in function and purpose it's a second stage bootloader for the 32bit kernel. But... a second stage bootloader designed as a realmode micro-kernel. (I'd be an idiot if I'd ignore the multiboot specification when I get to this point)

If in the end I decide to scrap this first project and start over I won't cry. But right now it's a design I still want to see thru to the (bitter) end.

If you end up doing a multistage bootloader, the typical design would be to implement the file systems (more than one) in the second stage and just use a block list in the boot sector. Having another partition just for the bootloader would be a bit awkward, so you'd want to have it on the same file system as the (primary) OS you're loading.

What does "microkernel" really mean though in the context of RM which doesn't have any protection mechanisms?

Kevin wrote:If you end up doing a multistage bootloader, the typical design would be to implement the file systems (more than one) in the second stage and just use a block list in the boot sector. Having another partition just for the bootloader would be a bit awkward, so you'd want to have it on the same file system as the (primary) OS you're loading.

Yeah, the problem is if you write a bootloader... you know what your goal is and you write it to do it's job as efficient as possible. But this is one creation that tries to be an OS and a bootloader but the latter only on a 386+. To complicate things even futher, theres no reason the 32bit OS couldn't be loaded by grub as a multiboot kernel directly. Am I driving you insane yet?

Kevin wrote:What does "microkernel" really mean though in the context of RM which doesn't have any protection mechanisms?

What does a microkernel really mean through the context of PM which has protection mechanisms? It's just a design philosophy, if I remember correctly there's even a multi tasking micro kernel for the CPC and MSX computers with a windows like gui.

Pure RM has limited resources so it's nice not to have a single blob of code in memory but something that's easier to adapt to the situation. If the RM kernel sees it's running on a 286 it should load a different memory manager that uses the loadall instruction to enable the use of high memory. But that added complexity would be a waste of resources when just running on a 8086/88. And having different kernels for ever little difference in architecture or hardware is just silly.

It's the runtime flexibility of the microkernel that I admire.

(With "the kernel seeing it's running on a 286", I mean the service in charge of dealing with deciding which other services to load.)