rfs (new filesystem for ELKS)
Hi again, I am working with the elks source and I am creating a new filesystem and would love some feedback on its design. It has the following properties: 1) All blocks are 1024 bytes in size. 2) the first 8K is managed as follows 1st 512 byte sector is solely used for a boot sector to load 7K bootup manager of choice. This is good because the sys program doens't have to worry about trashing the superblock as it installs the bootup manager of choice :) 2nd 512 byte sector is the superblock. The data in the superblock can be recreated if needed, so copies of it arn't required. the next 7 blocks (7K) is the boot manager. 3) The rest of the space is divided up into zones, each containing a maximum of 65536 blocks. 4) The first 8K of each zone is a bitmap of free blocks in the zone, 1 for used, 0 for free. 5) The rest of the zone is used for storing inodes/files. 6) Inodes are stored in exactly the same areas of file data and are 1024 bytes in size. 7) For files 1000 bytes in size (often dirs, symbolic links, many small files), the data is directly stored after the inode (great performace boost IMHO) 8) For files 1000 bytes, that space in the inode is used to point to blocks the data is really stored in. This allows files up to 256000 bytes to be stored, and offers decent performace. 9) For files 256000 bytes, that space is used to store pointers to blocks containing further pointers to blocks that store the data (indirect). This allows files up to the size of 65536000 bytes (64M) which should be more than enough :). 10) Inode numbers are really a combination of the zone and block. (32 bit number. High 16 bit is zone, low 16 bit is block). This allows file references to be picked up quickly. 11) Directores work like they do under ext2. This allows long fille names :) 12) The first inode will be a bad block inode that stores bad blocks. The second will be the root inode. That is about it for now. Please give me comments about the robustness, performace, memory usage, ect. Beau Kuiper [EMAIL PROTECTED]
Re: rfs (new filesystem for ELKS)
On Fri, 16 Jul 1999, you wrote: On Fri, 16 Jul 1999, Beau Kuiper wrote: 12) The first inode will be a bad block inode that stores bad blocks. The second will be the root inode. But what if the first or second inode gets trashed? Is there any way to rescue any data then? The bad block inode can be created by doing a bad block scan. But for the root inode, thinking about it now, i will have to change the layout slightly. I will reserve another 8K at the end of each zone to be a map of whether a block is a file or an inode. That way, if the a dir is trashed (along with the free page table), all lost inodes can be found. Thanks for pointing that out :). I could allow it to be disabled for non-vital filesystems that need more performace. Beau Kuiper [EMAIL PROTECTED]
RE: Microwindows for Hercules
No need. MicroWindows handles the Bresenham algorithm in the mid level code in devdraw.c. It uses successive calls to drawpixel to make it work. Hmm. A 8086 isn't quite a PC on which you want to loose performance. And that's exactly what you're doing here. PutPixel is a short routine and you loose way to much time if you don't inline it... In this way, people like you and me don't have to rewrite bresenham for every card someone wants You wouldn't have to rewrite it for every -CARD-, you would have to re- write it for every BIT-DEPTH. Which isn't that much work anyway. Chipzz AKA Jan Van Buggenhout -- UNIX isn't dead - It just smells funny [EMAIL PROTECTED] --
Re: Microwindows 0.83 released
Greg Haerr writes: MicroWindows version 0.83 is released at ftp://microwindows.censoft.com/pub/microwindows This version of MicroWindows is released in tandem with Al Riddoch's ELKS v0.78, which fixes a kernel select() bug with certain mice. The ChangeLog for this version is: Version 0.83 - 14th July 1999 - [EMAIL PROTECTED] * wrote sample untested hercules driver for ELKS * tweaked window repaint code to paint child windows last for ELKS * fixed code for pass-by-structure for bcc/ELKS * added TEST= for select() code in ELKS I'm looking for test volunteers for the new hercules graphics driver. This version runs well with ELKS and the window move problem in ELKS is also fixed. Please send comments and bug reports go [EMAIL PROTECTED] or the ELKS mailing list. I have built and tested 0.83, and it runs with no problems on my system. I only had to make the standard Makefile, and mouse settings changes. Responsiveness under nano-X is now much better. The mouse no longer lags when it is drawing in the top two windows. Screen updates in microwindows loook much nicer too. Good job all round. Al
RE: Microwindows for Hercules
: The place where nano-X and microwindows spend at *least* 95% of their
: pixel-pushing code is in drawing horizontal lines. All the demos but one
: *never* draw a diagonal line, the only case where bresenham is used. I had
: completed test cases to prove this...
:
: OK, granted. Nevertheless, does this mean it has to be slow? Suppose in
: the future someone writes a drawing program for ELKS, using the XOR algo
: to draw lines (and erase them again as the mouse pointer moves).
Yes, microwindows is ready for this, the code is already
commented out, waiting for somebody to add it. I just hadn't heard complaints
about the diagonal line drawing speed yet. (check out devdraw.c, and you'll
see that *if* the clipping routines see that the line can be drawn full speed
with no clipping, then a commented out low level routine can be called
to perform the function at blinding speed.)
: Hmm then that's something that could be checked for in between STOSB
: instructions (or the like). We could for example use something like this
: (just an idea), where ? is a flag that isn't used (maybe the carry flag?):
:
: PUSH flags register
: CLI
(we don't want to draw lines with interrrupts off)
: ...
: {If out needed} ST?
: ...
: {Bresenham}
: ...
: STOSB {or something like that, like OR}
: LOOPN?
: JN? :End
: ...
: {Perform OUT}
: ...
: LOOP
: ...
:
: :End
: ...
: POP flags register
:
: We could of course also use something else than a flag, like a register,
: if Bresenham doesn't already use all of them...
: Just an idea, I never did VGA 4 bit programming, I always used mode 13h.
:
Generally, it would be nice to have everything in asm for blinding
speed. I've already done this with microwindows and nano-X, see the file
asmplan4.s.. I also have everything written in C so that it's easily understandable,
and portable.
Why don't various people play with this code, and maybe
it should be part of the standard make?
Greg
RE: rfs (new filesystem for ELKS)
: 3) The rest of the space is divided up into zones, each containing a maximum of : 65536 blocks. : : 4) The first 8K of each zone is a bitmap of free blocks in the zone, 1 for : used, 0 for free. : : 5) The rest of the zone is used for storing inodes/files. : This is basically the BSD filesystem idea, right? : 6) Inodes are stored in exactly the same areas of file data and are 1024 bytes : in size. : : 7) For files 1000 bytes in size (often dirs, symbolic links, many small : files), the data is directly stored after the inode (great performace boost : IMHO) 1K inodes are great for big operating systems, but may not be a good idea for small ones. Nonetheless, this is interesting, and is the same thing that NTFS uses. I presume you've read all the lit on NTFS, because it has some really neat ideas for a new fs design, which is what you're attempting. : 10) Inode numbers are really a combination of the zone and block. (32 bit : number. High 16 bit is zone, low 16 bit is block). This allows file references : to be picked up quickly. : : 11) Directores work like they do under ext2. This allows long fille names :) : : 12) The first inode will be a bad block inode that stores bad blocks. The : second will be the root inode. Why not swap the two and have the first inode be the root inode, just like now? It might be nice to have the 1k inode size configurable. It also would be nice to write a utility that would show what the average file size is on a minix or ext2 filesystem. Greg
RE: rfs (new filesystem for ELKS)
: Actually, I have only studied the extent file systems, which are good for some : things (like performace on really big files and smaller files). For small : systems, these are not really suitable because they require too much caching, : esp for really small files. Under an OS like elks, this wastes a lot of space. : I probably should read about NTFS one day, but it sounds really complex (they : use B+ trees to store directory names). Such complexity is hard to do under : ELKS. The NTFS filesystem is documented in a small thin book available at many bookstores in the US. I don't know about down under. : : I choose the 1024 byte block becuase: : : 1) that is the size elks reads AFAIK when you read a buffer. : 2) you have a reasonable area to store small files. For small files, this : removes an expensive seek on the hard drive. Most directories are small files, : and will save much time over separated inode/data fs's. : 3) If i chose a smaller block size, there will be more overhead with the free : block bitmap, and i would probably need double indirect to store really large : files. I think the 1k block size is fine. : : Oh, BTW, the inode numbers i chose for root/bad blocks is abitary and : unimportant to the outside world. (I think (I am still learning)) : The inode number size *is* important, or the sys/stat.h structure has to change, causing all sorts of portability problems. Others may want to comment on this. Greg
RE: Microwindows for Hercules
A good idea, almost. The BOGL library performs this for the packed pixel :modes, but the VGA requires OUT instructions inbetween memory accesses, :so it can't run on a generalized bit-depth algorithm in planes mode. (The VGA :design has to be seen/studied to be believed, I've never seen such a complicated :piece of hardware for something kinda-conceptually simple) : : Although it would still require special case code, I believe that a : line-drawing routine for VGA16 would be relatively simple, since each : pixel is the same color. It's been a couple months since I've written : any VGA16 code, but IIRC writing a number of pixels all in one color : can be done with a specialized write mode that makes it easier. This is what we need. This special case code is already in the driver scr_bios.c under VGA_drawhline(). It calls either the C entry point in vgaplan4.c or the asm implementation in asmplan4.s called ega_drawhline. This code isn't optimized for multiple pixels with the same color, yet, and would most likely tremendously increase speed on slow systems like ELKS 8086's. Greg :
tiny sash typo
~elkscmd/sash/sash.c, line 382, #ifdef CND_ALIAS should be #ifdef CMD_ALIAS Anyway, CMD_ALIAS is not defined (c.f. sash/config.h).
RE: rfs (new filesystem for ELKS)
On Sat, 17 Jul 1999, Greg Haerr wrote: : Actually, I have only studied the extent file systems, which are good for some : things (like performace on really big files and smaller files). For small : systems, these are not really suitable because they require too much caching, : esp for really small files. Under an OS like elks, this wastes a lot of space. : I probably should read about NTFS one day, but it sounds really complex (they : use B+ trees to store directory names). Such complexity is hard to do under : ELKS. The NTFS filesystem is documented in a small thin book available at many bookstores in the US. I don't know about down under. I may read up on it sometime :) : : I choose the 1024 byte block becuase: : : 1) that is the size elks reads AFAIK when you read a buffer. : 2) you have a reasonable area to store small files. For small files, this : removes an expensive seek on the hard drive. Most directories are small files, : and will save much time over separated inode/data fs's. : 3) If i chose a smaller block size, there will be more overhead with the free : block bitmap, and i would probably need double indirect to store really large : files. I think the 1k block size is fine. : : Oh, BTW, the inode numbers i chose for root/bad blocks is abitary and : unimportant to the outside world. (I think (I am still learning)) : The inode number size *is* important, or the sys/stat.h structure has to change, causing all sorts of portability problems. Others may want to comment on this. Why has elks chosen a 16 bit inode number for stat when the rest of the world has 32 bit inode numbers? It probably is a good idea to use 32bit inode numbers. Beau KUiper [EMAIL PROTECTED]
