flat assembler
Message board for the users of flat assembler.

flat assembler > OS Construction > Idea for OS file system.

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
Consider this: just how often are you looking up filenames in applications today? How much time is spent on this, compared to the time spent on reading/writing data from/to the file?

As for "strings are error-prone"... get it right once, then stop worrying about it. Symbolic filesystems were invented for a reason - numeric filesystems imposed too many limitations.

It would be better to spend your time getting a decent blockdevice/cache/filesystem layering running, than inventing a new filesystem. The cache is one important thing, so are the used in-memory structures.

Also, forget about user:group and dword permissions, it's so 70s - even very conservative people like the BSD guys are moving on to ACL-based permissions.

You should perhaps have a look at the Reiser FS - it's pretty efficient.
Post 06 Apr 2004, 09:41
View user's profile Send private message Visit poster's website Reply with quote
anton



Joined: 08 Apr 2004
Posts: 17
Location: Moscow, Russia
JohnFound wrote:

One my idea about new OSes for discussion. Everyone knows that string operations are plague for assembler programming. String operations are slow and hard for programming. In other hand filenames and paths in every FS are strings, so on every opening of the file OS must work with strings. So the idea:

What if every file in the operating sistem have some unique number instead of string file name. In addition, for human reading, the OS may support some database with string aliases of the files.

Everyone knows that big OS opens continuously, hundreds of system files, libraries, etc. If the OS identify this files with numbers, not with strings this process will be very fast.

Second: It will be possible to change the place of the files, without changing their numbers, so, there will be option freely to move applications on different directories, because the actual number of the file will be the same and only it's alias will be changed.

Third: If list with files is sorted (it's not a problem) the search for file with given number will be very fast.

So, what you think about this idea?


Hello.

This is good idea.
But I think string file names is not problem. New processors (with Ghz kernel) may process strings extrimely fast (in comparition with disks access time).
There is other problem. 8-bit ASCII string coding is not optimal. Many characters cannot be used. (0-31, 128-255 and other).

My idea is to use 6-bit string coding. It allow to use 64 characters: 26+26 (big and small) - latin characters, 10 - dec numbers, and underline character ( "_" ). Character with number 0 - string terminator.

There is other idea to use 6-bit string coding with numbering (your idea).
Post 09 Apr 2004, 12:04
View user's profile Send private message Reply with quote
anton



Joined: 08 Apr 2004
Posts: 17
Location: Moscow, Russia
There is question for JohnFound.
How users will identify their files? By numbers? It makes their to remember file numbers. I think that is not good.
Post 09 Apr 2004, 12:19
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
anton wrote:
There is question for JohnFound.
How users will identify their files? By numbers? It makes their to remember file numbers. I think that is not good.


Of course it is not good. Wink And of course, there will be some simple data base with human readable names of the files. The advantage is that the programs will find it's files by number and if the human readable names are deleted, all applications will work OK.

Reagrds.
Post 09 Apr 2004, 12:52
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
anton



Joined: 08 Apr 2004
Posts: 17
Location: Moscow, Russia
Question to JohnFound.
What you think about 6-bit filename string coding. (see my previus messages)?
Post 09 Apr 2004, 13:09
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
anton wrote:
Question to JohnFound.
What you think about 6-bit filename string coding. (see my previus messages)?


Actually I think that modern OS should have unicode names. And about novadays CPU that can process strings without problems - I think that there are better tasks for CPU than processing strings all the time. Smile

Regards
Post 09 Apr 2004, 13:26
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
I wonder if filenaming parsing is a problem at all with modern filesystems, even with rather slow processors like 200mhz and below. Has anybody ever time this, or does the idea come from "I don't like fiddling around with filename parsing myself"? Smile

If the idea of numeric files + filename database is used, doesn't this make the filename database very vulnerable to disk errors, filesystem bugs, etc? (assuming the database is kept in one place).

Did you study any existing filesystems before coming up with this idea?

Also, I agree with JohnFound about unicode. I really hate unicode and thing that ll other languages should be discarded in favour of english, but... I also live in the real world Wink, and OEM charsets are more problems than they're worth (not to mention they probably won't do very well for stuff like chinese?)
Post 09 Apr 2004, 21:32
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
Hi f0dder.

Actually, when I open this thread (look at the date of the first post) I never think that it will become so popular. Smile This is simply very raw idea about FS for my future ( Very Happy ) OS.

f0dder wrote:
I wonder if filenaming parsing is a problem at all with modern filesystems, even with rather slow processors like 200mhz and below. Has anybody ever time this, or does the idea come from "I don't like fiddling around with filename parsing myself"? Smile


It depends of how the software is written. The OS make filename processing on every "open" of the file. So, the importance (in terms of speed) of this processing depends of many factors: If the program needs to read many small files, filename parsing can take veen more time than real reading of the data. Also, you know, the developper can simply make sequences like this with one file: "open, read 10 bytes, close, open, read another 20 bytes, close, and so on many times). Of course all this can be optimised with better written software, but in big projects like open source OS, where many programmers write different parts of the OS, such optimizations are very hard to be provided. So, if the OS works mainly with numeric identifiers, some of these problems can be avoided.

Quote:
If the idea of numeric files + filename database is used, doesn't this make the filename database very vulnerable to disk errors, filesystem bugs, etc? (assuming the database is kept in one place).


Well, I don't think it will be more vulnerable than FAT structure for example, but note that destroing FAT means total lost of all files, but destroing the filename database will means only lost of filenames (in most cases only the part of filenames) but the files can be restored with simple scan of the disk for first file sectors. Actually in above described FS there is not possible to destroy all files at all destroing some data on the disk.


Quote:
Did you study any existing filesystems before coming up with this idea?


No, I am not. But my OS is in the stage of ideas and I never though that so many people will be interested. Wink btw: This FS is not exactly my idea. The most of the ideas are from FS of DOS 3.3 for Apple II computers. Many ears ago, I wrote the OS compatible with DOS 3.3 as school project and I implemented this FS in it. Later on PC XT, I began to wonder why the FAT system is implemented in so stupid way that destroing one sector of the disk may destroy all files.

Quote:
Also, I agree with JohnFound about unicode. I really hate unicode and thing that ll other languages should be discarded in favour of english, but... I also live in the real world Wink, and OEM charsets are more problems than they're worth (not to mention they probably won't do very well for stuff like chinese?)


I think that this is simply because we are so used to 8 bit ASCII table. UNICODE is good idea (but AFAIK not in MS implementation that is different from the standard)

Regards
Post 10 Apr 2004, 08:23
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
neonz



Joined: 02 Aug 2003
Posts: 62
Location: Latvia
JohnFound wrote:
Hm, I don't know how Linux reaches this (are you sure?), but at first:
It is possible to use multiply GDT. At second - do you actually need 65000 processes? In most cases you should make multy-thread program, not multiprocess.


Linux does not have TSS for each process.
It only uses TSS task switching when changing cpl (cpl0 <-> cpl3).

IMHO
Post 11 Apr 2004, 11:42
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2019, Tomasz Grysztar.

Powered by rwasa.