OSDev.org

1: on floppies, the superblock is the first sector. The reserved area is whatever you want to reserve for bootloaders and second stage loaders. If you want a second stage to be loaded from the filesystem, the amount of reserved sectors equals one - the bootsector itself, otherwise, add as many sectors as your second stage needs.

2: SFS floppies are just as bootable as FAT or any other homebrew format. Just make sure the last word has to correct magic number (thats 0x55AA iirc)

3: That's meant to eliminate steps in filesystem reading - you can look everything up in the index without having to seek all over the disk to recurse through several directories. Basically its SFS thinking.

4: There are no references to deleted files anywhere, only holes. This is just a sort of laziness, you just empty the index entry and be done with it.

5: if you do KISS, yes, but if you want you can employ some advanced logic to shift the file to where it can eat the space it needs

6: Two methods: you loop through the index and check for every block if its used or not, like a bitmap. Otherwise you check the distance between data area end and index start (Index and data area can grow, the unused space between them will, obviously, be unused). Personally i use the last method, and then attempt to defragment when theres no space left there.

I find that so simple and lazy that it's complex
it makes it a bottle neck with you at the other end of the bottle(fast until something unusual happens)

SFS isnt designed to be fast, only simple and free of copyright issues. I dont see any more complexity than what i add myself

Hate to pull a dead thread from the wastes, but the website seems to be dead & gone again. Brendan, do you still have the spec & can I put up a backup for it?

Candy wrote:Hate to pull a dead thread from the wastes, but the website seems to be dead & gone again. Brendan, do you still have the spec & can I put up a backup for it?

...should've made a backup while I had the chance...

With your permission, can I host a copy on my website together with my implementation?

Hi,

Candy wrote:Hate to pull a dead thread from the wastes, but the website seems to be dead & gone again. Brendan, do you still have the spec & can I put up a backup for it?

It seems my entire web site has finally gone (the web host told me they were closing down about a month ago). Sooner or later I'll redirect everything back to my home server (like it was before I started using the web host), but to be honest, lately I've been writing (um, playing with) a new language/compiler for OS dev and probably won't worry about my web site for a while.

Combuster wrote:With your permission, can I host a copy on my website together with my implementation?

I've attached the SFS specification to this message. It's intended as a "fully open" standard - no permission required...


Thanks,

Brendan

http://www.atlantisos.org/sfs.html

Thanks for the document.

Combuster, care to cross-link the specs so we have a fair bit of reliability?

Brendan, is this the final version or are you going to change it?

Candy wrote:http://www.atlantisos.org/sfs.html

Thanks for the document.

Combuster, care to cross-link the specs so we have a fair bit of reliability?

Brendan, is this the final version or are you going to change it?

Just an idea, But perhaps a central site should be setup for maintaining the document.

It could also index various implementations etc? Would Sourceforge work?

Brendan wrote:I've attached the SFS specification to this message.

Thanks

Brendan wrote:It's intended as a "fully open" standard - no permission required...

Its just difficult to read legal bla-bla when there is nothing to read

Candy wrote:Combuster, care to cross-link the specs so we have a fair bit of reliability?

I put up a copy at http://dimensionalrift.homelinux.net/co ... k/sfs.html - People can also reach it through my signature.

Candy wrote:Brendan, is this the final version or are you going to change it?

I consider the specification pretty much stable. The changes of past year were mainly for readability.

Brynet-Inc wrote:Just an idea, But perhaps a central site should be setup for maintaining the document.

There was a forum on (linked from?) Brendan's site, but since I only visited it through his webpage I don't have any links and it might be very well down with the rest of the site - you should ask.

Brynet-Inc wrote:It could also index various implementations etc? Would Sourceforge work?

I am not so inclined to use SF. Especially since this is a technical paper rather than a piece of software. I'd wait for the forums to be back or otherwise dedicate a page or two on the wiki to it.


[edit]@mods: i think this forum would be more appropriate for os theory?[/edit]

Hi,

Candy wrote:Brendan, is this the final version or are you going to change it?

I don't intend to change the file system itself, but sooner or later I'll probably make some more improvements to the specification (e.g. adding some psuedo-code to Appendix A, etc). It won't be any time soon though - I feel like I'm chipping away at an iceberg with a toothpick at the moment...

@Combuster: There was a sub-forum for SFS on my web site, but the web host got hacked and the forum database wasn't backed up very regularly, most of the posts where spam and I was spending too much time maintaining my web site and not enough time writing OS code. At the time I was starting the newest version of my OS, so I dumped the entire web site (including all the forums) and switched to a new layout, without the forums.

BTW I've got my home server setup and changed the DNS, etc. It should be possible to get the SFS specification from http://bcos.hopto.org/sfs.html. This is a "limited bandwidth" server with dynamic IP though...


Cheers,

Brendan

Ok, sorry for raising this thread from the grave, but when searching for SFS specs, I found many file systems named SFS, e.g.:

- Secure FileSystem
- EROS Simple Filesystem
- Self-certifying File System
- Simple File System
- SingleFileSystem (not an FS)
- OS/161 sfs file system
- IBM TotalStorage SAN File System

Well, I could go on but you get the point. Perhaps we should rename SFS to something a tad bit more unique? :)


JAL

Hi,

Do I gain this month's thread necro prize?

I'm rewriting my tutorial series from scratch, and wanted to implement a "real" filesystem as one of the chapters. SFS really seems exactly what I'm after - I'll write a set of command-line "mtools" style tools to deal with it too - however as the tutorial series creates a UNIX-like OS there are a few things SFS is missing, namely character and block devices.

Sockets and named pipes I don't really care about, but char and block devices are fairly essential. There seem to be a number of unused index area entry identifiers - would an addendum that added these two filetypes to the specification be acceptable? I'm happy to draft it up.

Cheers,

James

JamesM wrote:Do I gain this month's thread necro prize?

It's probably a bit early in the month to be claiming a win yet.

I don't have a lot of say in the matter, but it would seem to me that this sort of thing should be optional, so that the core of the filesystem can remain what it says it is: simple. If I were using SimpleFS in my bootloader, I wouldn't want to have to care about UNIX devices. $0.02

Quite. However, they're so simple that ignoring them would be just adding two extra cases to your "switch (type)" statement, reading the number of continuations (just like in a directory or file) and skipping over them.

I can't see it being much hassle...

Linux uses devfs/udevd/procfs and the like, which basically mounts a different filesystem under a different mountpoint. Following that analogy you could just reuse the VFS structure and put devices where they can be put and use SFS for the root.

Besides I don't think its a good idea to taint SFS with unix-specific properties since that goes straight against its principles.