Black Manticore

by lunarg on July 28th 2007, at 23:02

General information

Has no journalling, so preferrably only used for CF and USB sticks, or for very small file systems where journalling makes things worse than better.
No indexing, so don't use for many files.
Preferred choice for external storage, because virtually all systems can read ext2/ext3 (including Windows with proper software).

Has journalling. Is perfect for all-round (server) systems, in particular root file systems and such. If there are many small files, and many files in one directory, this one is not the preferred choice because there's no specific indexing method (or none that I know of).
Has full resize support, so can be used for LVMs.
Is robust: has proven its worth.
Disaster recovery percentage is higher than other file systems.
Preferred choice for external HDs, because virtually all systems can read ext2/ext3 (including Windows with proper software).

Has journalling. Is perfect for desktop systems and storage for small and many files.
Has B-tree indexing, and thus is pretty fast when looking up files.
Has full resize support, so can be used for LVMs.
Usually doesn't require fsck-ing, unless with disaster recovery.
Doesn't use inodes, so can virtually hold unlimited amount of files per directory (in reality, it is limited though).
Uses tree based extent storage: files are always stored near optimally, reducing fragmentation.
Uses file packing: small files are packed together in a single block, reducing storage slack drastically.
In case of physical failure, chance of data recovery is slim, especially when the meta data structures are damaged.
Preferred choice for desktop systems, and any other system with lots of file handling.

Experimental. Designated to be a complete new file system as a sucessor for ext2 and ext3.
Uses B-tree indexing.
FIXME

Has journalling. Uses an advanced system for storage, based on the way a database would work, using allocation groups, multiple localized log files.
Can handle many and large (2MB and up) files more efficiently.
Doesn't use inodes, so can virtually hold unlimited amount of files per directory (in reality, it is limited though).
Is a multi-threaded file system, and provides considerate speed ups when comparing to other non-threaded file systems on SMP machines.
Uses extent based storage, divided across multiple allocation groups. Because of XFS's multi-threaded architecture, it is possible to read and write simultaneously to different allocation groups, allowing for more different tasks to be executed at the same time.
Needs to be defragmented occasionally, especially with lots of operations on many small files.
Can only resize upwards (grow), not downwards.
Preferred choice for server systems with large and many files. In particular a good choice for SMP systems which have to perform lots of different tasks.

Is still experimental.
Has same benefits as reiserfs (reiser3), but is multi-threaded.
Is extremely fast for read operations, especially on a huge number of small files.
Is very fast for write operations on many small files.
Is not so fast on write operations on medium to large files.
Uses storage in dancing trees. This method continuously tries to improve performance by reorganizing files so they can be accessed even faster.
Requires a fast HD and architecture because of background reorganizing.
Preferred choice for desktop systems with fast HDs, and any other system with lots of file handling, but with emphasis on reading, and not writing.
It is the perfect choice if your root file systems (where programs are stored) is seperated from your data storage. Since programs are not updated as often (usually only read), using reiser4 for this, considerably decreases loading times of your software.