| | 1 | = Issues with BFS = |
| | 2 | |
| | 3 | |
| | 4 | BFS has several issues that can only be solved by breaking binary compatibility. To solve all of them, It's a better idea |
| | 5 | to start a new file system (based on the BFS sources) than to try to remain compatible. |
| | 6 | |
| | 7 | To 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 | |
