Changes between Initial Version and Version 1 of FutureHaiku/BFSIssues


Ignore:
Timestamp:
Oct 26, 2009 2:43:15 PM (10 years ago)
Author:
mmadia
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FutureHaiku/BFSIssues

    v1 v1  
     1= Issues with BFS =
     2
     3
     4BFS has several issues that can only be solved by breaking binary compatibility. To solve all of them, It's a better idea
     5to start a new file system (based on the BFS sources) than to try to remain compatible.
     6
     7To mention the ones I currently remember without further investigation:
     8 * The space of files that were deleted, but still in use is lost after a system crash (checkfs fixes that, so it's a good idea to run it from time to time after crashes).
     9 * There is a global block bitmap that could solved better using some tree.
     10 * The index is not written for user queries (looking up wildcards can be pretty expensive).
     11 * There is a single fixed size log which theoretically prevents some operations from happening (those that doesn't fit into the log anymore).
     12 * Writing meta data is essentially single threaded (as there is only one log).
     13 * The double indirect block range is implemented in a stupid way which makes it almost useless (it could cover a lot more space easily).
     14 * No support for hard links.
     15 * One inode covers a whole block, and it only embeds attribute data into that block (could do the same with file data).
     16 * Potentially scatters inodes over the whole disk (somewhat balanced by its allocation policies) that aren't optimal for directory reading speed.
     17 * The B+trees fragment over time.
     18 * No data correctness facilities (ie. data cannot be placed in the log, and there are no checksums either).
     19 * The indexes hurt performance as they are updated synchronously.
     20