Brendan wrote:
Hi,
pauldinhqd wrote:
let me know your suggestions if possible, tks in advance
If you want to develop a new high performance file system; I'd start by splitting it in half - a lower level part and a higher level part.
The lower level part would mainly manage "linked lists of extents" - allocating new extents, freeing them, resizing them, reading them and writing them. Naturally it'd also manage free space, handle things like bad sectors, etc; and it'd probably be the best place to do things like "sparse lists of extents" (used for sparse files support), encryption, compression, etc.
The higher level part relies on the lower level part. A file's data is just a linked lists of extents. Directories are linked lists of extents that contain directory entries instead of file data. More advanced things like snapshots and
forks are just more linked lists of extents.
If you split things like this you should be able to test the lower level part on its own; and could possibly have several "lower level parts" and several "higher level parts" and combine them in various ways. For example, perhaps one "lower level part" that tries harder to avoid moving extents for SSD and USB flash, and another "lower level part" that tries harder to avoid fragmented extents for hard drives; and perhaps one "higher level part" designed to be efficient for lots of small files and one designed to be efficient for lots of large files (plus maybe a stable version of each and a beta/development version of each).
Cheers,
Brendan
These are great points however I'm still a bit confused whether linked-list
may give good performance, coz, let say when we need to find some file with its
name and its path, it seems that we to have to scan 'linearly' thru' certain linked-lists,
and what if these linked-lists contain lots of items
Possible to allow O(logN) file search on these linked-lists
What may happen when we seek to a byte in a very large file
rdos,
I'm trying not to do double work :p