File Management: Difference between revisions
| [unchecked revision] | [unchecked revision] |
m (added category) |
mNo edit summary |
||
| Line 3: | Line 3: | ||
A [[monolithic kernel]] handles everything in one monolithic (hence the name) process. A [[Microkernel]] consists of several processes which are responsible for all the grunt work: allocating memory, managing processes - and housekeeping permanent data storage like hard disks or floppies. Yes, about [[File Systems|filesystems]] the talk is. |
A [[monolithic kernel]] handles everything in one monolithic (hence the name) process. A [[Microkernel]] consists of several processes which are responsible for all the grunt work: allocating memory, managing processes - and housekeeping permanent data storage like hard disks or floppies. Yes, about [[File Systems|filesystems]] the talk is. |
||
Say, we have a file system service. It is responsible for keeping the File System on a Floppy/HD what so ever up to date (and eventually handle pipes and so forth...) The very basic -- the uttermost basic task of the file system service is to keep track of allocated/deallocated blocks and (in case of ext2) inodes - files, to which blocks are allocated - you also need blocks for the file/block management. Another task a file system service usually performs, is keeping blocks in memory for quick access. They are slow to retrieve from disk storage - compared to a simple memory access. So the file system service keeps the so called block cache. Now, think about it: you use paging, you have the file system service as a process of its own. It fetches blocks and keeps them in its |
Say, we have a file system service. It is responsible for keeping the File System on a Floppy/HD what so ever up to date (and eventually handle pipes and so forth...) The very basic -- the uttermost basic task of the file system service is to keep track of allocated/deallocated blocks and (in case of ext2) inodes - files, to which blocks are allocated - you also need blocks for the file/block management. Another task a file system service usually performs, is keeping blocks in memory for quick access. They are slow to retrieve from disk storage - compared to a simple memory access. So the file system service keeps the so called block cache. Now, think about it: you use paging, you have the file system service as a process of its own. It fetches blocks and keeps them in its address space. |
||
You'll have to do lots of work to transfer the data of a retrieved block to a user process which performs the read() call - or vice versa a write(). |
You'll have to do lots of work to transfer the data of a retrieved block to a user process which performs the read() call - or vice versa a write(). |
||
Revision as of 17:18, 6 September 2010
This has been contributed to the Pro-POS Wiki by "Beyond Infinity". He agreed to have it forwarded here due to its catch-all nature. -- MartinBaute
A monolithic kernel handles everything in one monolithic (hence the name) process. A Microkernel consists of several processes which are responsible for all the grunt work: allocating memory, managing processes - and housekeeping permanent data storage like hard disks or floppies. Yes, about filesystems the talk is.
Say, we have a file system service. It is responsible for keeping the File System on a Floppy/HD what so ever up to date (and eventually handle pipes and so forth...) The very basic -- the uttermost basic task of the file system service is to keep track of allocated/deallocated blocks and (in case of ext2) inodes - files, to which blocks are allocated - you also need blocks for the file/block management. Another task a file system service usually performs, is keeping blocks in memory for quick access. They are slow to retrieve from disk storage - compared to a simple memory access. So the file system service keeps the so called block cache. Now, think about it: you use paging, you have the file system service as a process of its own. It fetches blocks and keeps them in its address space.
You'll have to do lots of work to transfer the data of a retrieved block to a user process which performs the read() call - or vice versa a write().
Check out, how it would be to have a task in kernel space keep the block cache and performing the actual reading/writing.