Omnimaga

Calculator Community => Discontinued => Major Community Projects => KnightOS => Topic started by: SirCmpwn on September 27, 2010, 10:52:34 pm

Title: Knight Filesystem Specification
Post by: SirCmpwn on September 27, 2010, 10:52:34 pm
Attached is the specification for KFS, please review this if you have time and let me know what kind of feedback you can give.  Garbage collection is not fully thought out at the moment, so I know this portion of the document is inaccurate.  In addition, one error in this version is the page byte, this should be added so that the file entry looks as follows:
Code: (File) [Select]
Type ID (11111110b for file) Byte
Directory ID Word ; The directory containing the file
Name (0 delimited)
Page byte ; The flash page the file starts on
Offset Word ; The offset from the start of that page (+4000h) the file is on
Title: Re: Knight Filesystem Specification
Post by: calcdude84se on September 27, 2010, 11:06:56 pm
Will read when I have the chance. Good luck on figuring out garbage collection!
(On an unrelated note, I'm done with the main planning and will begin coding (my OS :P) :))
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on September 27, 2010, 11:15:16 pm
Yay ^_^
Title: Re: Knight Filesystem Specification
Post by: DJ Omnimaga on September 27, 2010, 11:27:44 pm
I'll check this when I have a minute and nice to hear Calcdude84se :D
Title: Re: Knight Filesystem Specification
Post by: LordConiupiter on September 28, 2010, 05:18:45 pm
wow nice! Those things really are the most beautifull things to make in life IMO :D Your own working data storage system. Won't this have compatibility issues with the TIOS files? And will it be possible to send data to your calc when KnightOS is installed on it using TIconnect/TiLP? When this won't be possible, which I guess being true, will you write your own data transferring program?
Title: Re: Knight Filesystem Specification
Post by: calcdude84se on September 28, 2010, 05:30:09 pm
To answer your question to the best of my knowledge, yes, the TI-OS file system is wholly incompatible with the KFS. However, he plans a feature that, on first setup, allows you to do a special reformatting. (I don't know if that will be done.)
Providing he implements the protocol, it will be possible to transfer data via TI-Connect or TiLP. (I presume files will be "wrapped" into TI-OS formats for linking programs/TI-OS based calcs.)
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on September 28, 2010, 06:15:54 pm
First question, I plan on having the installer move all of your TIOS files into a directory in KFS when it is reformatted.  The VAT (TIOS Filesystem) is completely incompatible (the main reason dual boot is out of the question).  I will possibly write my own linking program, but TI Connect support is also planned.
Title: Re: Knight Filesystem Specification
Post by: calcdude84se on September 28, 2010, 06:17:38 pm
Thanks for clarifying. It also appears I forgot to explicitly state the effects/purpose of the special reformatting. :P
Title: Re: Knight Filesystem Specification
Post by: Deep Toaster on September 28, 2010, 09:17:18 pm
Yay, does this mean you're done working on the KFS? :D

Also, a random question (I probably don't know what I'm talking about): How would you tell the difference between garbage entries and simply nonexistent ones?

And would 2ND+[OFF] actually turn the calc completely off in the OS?
Title: Re: Knight Filesystem Specification
Post by: calcdude84se on September 28, 2010, 09:22:07 pm
Sadly, there's no way to turn the calc completely off without removing all the batteries. That's just the hardware.
And that random question is confusing me. (Not that I am confused about the FS, but rather the question itself) ???
Title: Re: Knight Filesystem Specification
Post by: Deep Toaster on September 28, 2010, 09:32:31 pm
Well, it says that 0000000b is for "garbage" entries, but what if it's already deleted?

EDIT: Oh, wait, they're all in flash. Never mind.
Title: Re: Knight Filesystem Specification
Post by: calcdude84se on September 28, 2010, 09:35:33 pm
Oh, you thought it was RAM. Okay, that makes more sense.
Glad to know you've figured it out. :)
Title: Re: Knight Filesystem Specification
Post by: Deep Toaster on September 28, 2010, 09:37:42 pm
Yeah. Well, about that, if you can't turn the calc completely off, why keep everything in flash? Is it just to protect against mem clears?
Title: Re: Knight Filesystem Specification
Post by: calcdude84se on September 28, 2010, 09:39:21 pm
Pretty much, not to mention flash has so much more storage space. (Or in case you have to change the batteries.)
Rather important also if the system can be brought down in two bytes.
Code: [Select]
di
halt
Title: Re: Knight Filesystem Specification
Post by: Deep Toaster on September 28, 2010, 09:41:57 pm
Oh, okay. And just wondering: If it were to delete vars instead of marking them for garbage, would that be more damaging to the flash chip? Meaning does each write to it do just as much wearing no matter how small it is?
Title: Re: Knight Filesystem Specification
Post by: calcdude84se on September 28, 2010, 09:43:53 pm
What wears a flash chip is erasing it (setting all the 0 bits back to 1's)
However, having it clean up after each deletion rather than all at once would be slower and yes, it would probably wear the flash more.
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on September 28, 2010, 10:08:15 pm
I'm thinking of doing a garbage collection at boot, to avoid locking up the entire system for a garbage collection while saving a file.  Thoughts?
Title: Re: Knight Filesystem Specification
Post by: calcdude84se on September 28, 2010, 10:12:32 pm
Well, how long will a garbage collection take? If it's no more than ~30sec, I see no problem in making it an atomic operation, IMO.
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on September 28, 2010, 10:13:33 pm
I would estimate it at 10-20 seconds.
Title: Re: Knight Filesystem Specification
Post by: calcdude84se on September 28, 2010, 10:17:39 pm
At least IMO it's fine. It's not like they'll happen at a very great frequency anyway... and since you can completely pause any running program (or, more advanced, just those that are using files in the FS being garbage collected ;)) it doesn't seems like it'd be too bad.
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on September 28, 2010, 10:19:29 pm
Ooo, it might be a good idea to freeze file streams when garbage collections are in progress, instead of only allowing one file at a time.  This is something I've been struggling with: how to edit multiple files at once?  I know I will probably use filestreams to make it easier on the user to cross page boundaries and such.  But I'm still not sure how to handle multiple pages.
Title: Re: Knight Filesystem Specification
Post by: calcdude84se on September 28, 2010, 10:24:30 pm
Ooo, it might be a good idea to freeze file streams when garbage collections are in progress, instead of only allowing one file at a time.
Elaborate, please, I'm confused. ???
Quote
This is something I've been struggling with: how to edit multiple files at once?
What's getting in your way?
Quote
I know I will probably use filestreams to make it easier on the user to cross page boundaries and such.
Do programs handle flash almost directly, or am I misunderstanding?
Quote
But I'm still not sure how to handle multiple pages.
As above, but also, sectors might be a worry too.
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on September 28, 2010, 10:26:53 pm
I think that a solution to the multiple files problem is making programs define the size beforehand.  As for programs handling flash directly, I would prefer they use filestreams in the OS to handle it, because the OS will handle the page boundaries.  A filestream is a means to reading and writing files or memory, or in KOSes case, only files.
Title: Re: Knight Filesystem Specification
Post by: calcdude84se on September 28, 2010, 10:31:02 pm
You still haven't answered my question of how are multiple files a problem. :P
Also, I thought you earlier had an idea of "edit buffers" or something like that where programs edited pieces of a file one piece at a time in RAM. Was that scrapped?
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on September 28, 2010, 10:47:28 pm
It will probably be scrapped, seeing as most files will probably end up being too big.  I don't want to edit files that take up most of available RAM.  In KFS, three bytes are dedicated to filesize, and I want to make sure I support that.
As for editing multiple files, if two files are growing in flash alongside each other, there will be significant problems unless I garbage collect every time a byte is written.
Title: Re: Knight Filesystem Specification
Post by: calcdude84se on September 28, 2010, 10:50:50 pm
Why would you be garbage collecting? If one file encroaches on another, you'll have to delete and move it (unless you can't ???), and I recommend you make provisions to be able to skip a certain amount of extra space after file to prevent what you and I described from happening :)
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on September 28, 2010, 10:51:39 pm
Delete+move would mean that the garbage would pile up very quickly.
Title: Re: Knight Filesystem Specification
Post by: calcdude84se on September 28, 2010, 10:53:04 pm
Definitely, hence why I recommend providing extra space at the end of a file :D (And make sure you don't update the size byte in flash until the file is closed :P)
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on September 28, 2010, 10:55:49 pm
Yeah, I'm not sure about that.  I'll think it over for a bit.  Imagine if two programs were writing large files, multi-page, perhaps.  It might garbage collect 10 times over the course of saving them.
Title: Re: Knight Filesystem Specification
Post by: DJ Omnimaga on September 28, 2010, 10:59:31 pm
Garbage collecting at boot seems like a good idea, as long as it won't wear the flash chip faster if it garbage collects even when the memory is not very fragmented

Keep up the good work on KnightOS :D
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on September 28, 2010, 11:00:32 pm
It may count up the garbage and see if it's worth garbage collecting or not.
Title: Re: Knight Filesystem Specification
Post by: DJ Omnimaga on September 28, 2010, 11:04:09 pm
Ah sounds good :)

If someone doesn't reboot for a long while, I assume it will automatically GC when needed?
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on September 28, 2010, 11:04:27 pm
Yes.
Title: Re: Knight Filesystem Specification
Post by: calc84maniac on September 28, 2010, 11:05:02 pm
What if someone decides to replace the batteries?
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on September 28, 2010, 11:05:59 pm
Nothing would be different... O_o
Title: Re: Knight Filesystem Specification
Post by: DJ Omnimaga on September 28, 2010, 11:06:37 pm
Ok good. Also, if you make your own linking software, will we be able to send any kind of file to the calc like on the TI-Nspire? On the TI-Nspire, if you want to send a Gameboy Color ROM, all you do is add a .tns extension at the end and you're set. I assume TI-Connect would not accept such file, though, right?

Also for batteries, will there be some protection against battery removal/dying during GC'ing? Or will it do like on the 83+ and random archived files vanish?
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on September 29, 2010, 08:30:17 am
It will check the battery state before starting, and probably inform the user that they should change the batteries really quick before the GC starts, and inform them of possible data loss.
As for files, you can send any file you like to KOS.
Title: Re: Knight Filesystem Specification
Post by: DJ Omnimaga on September 29, 2010, 12:37:16 pm
Great!
Title: Re: Knight Filesystem Specification
Post by: Deep Toaster on September 29, 2010, 11:38:05 pm
It may count up the garbage and see if it's worth garbage collecting or not.

Sounds good, then. But what if it really needs to garbage collect in the middle of an operation or something? It's still gotta take that into account, and then it might as well just wait until then to do it instead of checking at boot.
Title: Re: Knight Filesystem Specification
Post by: DJ Omnimaga on September 29, 2010, 11:41:41 pm
Another thing: it would be nice to not call it Garbage Collecting. I always found this weird. It might be best to call it defragmenting or something, like when deleting an APP. In French, Garbage Collect is Memory Reorganizing, anyway. The first time I saw GC, I thought the calc was asking me to do a mem reset...
Title: Re: Knight Filesystem Specification
Post by: Deep Toaster on September 29, 2010, 11:43:23 pm
Yeah, I guess it does sound a bit weird...
Title: Re: Knight Filesystem Specification
Post by: Raylin on September 30, 2010, 12:27:23 am
Agreed. Calling it Defragment is much more unambiguous.
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on September 30, 2010, 08:39:48 am
Another thing: it would be nice to not call it Garbage Collecting. I always found this weird. It might be best to call it defragmenting or something, like when deleting an APP. In French, Garbage Collect is Memory Reorganizing, anyway. The first time I saw GC, I thought the calc was asking me to do a mem reset...
This may be the case, but I didn't make the term: http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29 (http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29)
Title: Re: Knight Filesystem Specification
Post by: DJ Omnimaga on September 30, 2010, 09:28:38 am
Ah, right x.x. Well, if you call it that way, then it might be good to make it very visible somewhere in the readme or OS that this is just about fragmented mem that needs to be reorganized or something. That said, most ppl who may use your OS will probably be experienced calc users but some people with less experience may start using the shell later too if many software/games they want are made available only for KnightOS or if they get the OS from someone at school.
Title: Re: Knight Filesystem Specification
Post by: Deep Toaster on September 30, 2010, 11:58:55 am
Yeah, my first reactions after finding the GarbageCollect feature when I got my calc were (in this order):

Also, wouldn't it be a waste to check for garbage at boot? It would have to check while saving stuff no matter what, and at the rate some of us use our calcs, we might have to garbage collect several times during use anyway.
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on September 30, 2010, 05:12:16 pm
Well, I still haven't implemented it yet.  We'll see.
Title: Re: Knight Filesystem Specification
Post by: DJ Omnimaga on September 30, 2010, 05:15:29 pm
I personally feel it should maybe only do it if the isn't a lot of remaining archive sectors that aren't fragmented. I guess it might be best to wait a bit, though. What are you working on next on KOS, btw, Sir?
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on September 30, 2010, 05:16:38 pm
Next, I'm working on libraries, then making the filesystem conform better to KFS and be writable, then I'm releasing the kernel.
Title: Re: Knight Filesystem Specification
Post by: DJ Omnimaga on September 30, 2010, 08:26:23 pm
Ok, cool to hear. Good luck :)

I can,t wait to try it :D
Title: Re: Knight Filesystem Specification
Post by: Eeems on October 24, 2010, 09:43:35 pm
Just noticed this topic, and I had a thought, isn't it also defragmenting? Garbage Collection in the way we are doing it seems to fit Defragmentation more.
Also, How about having it scan the filesystem and see if defragementing is a good idea before doing it? Like see how fragmented it is first, and if it is below a certain percent then it wont defragment
Title: Re: Knight Filesystem Specification
Post by: SirCmpwn on October 24, 2010, 09:45:43 pm
Well, it should only do this when the filesystem is full.
Title: Re: Knight Filesystem Specification
Post by: Eeems on October 24, 2010, 09:47:03 pm
Ah ok, that makes more sense :)