mirror of
https://github.com/trapexit/mergerfs.git
synced 2026-10-20 19:48:32 +00:00
Improve mergerfs intro in docs (#1563)
This commit is contained in:
+47
-16
@@ -1,14 +1,41 @@
|
||||
# mergerfs - a featureful union filesystem
|
||||
|
||||
**mergerfs** is a
|
||||
[FUSE](https://en.wikipedia.org/wiki/Filesystem_in_Userspace) based
|
||||
[union filesystem](https://en.wikipedia.org/wiki/Union_mount) geared
|
||||
towards simplifying storage and management of files across numerous
|
||||
commodity storage devices. It is similar to [**mhddfs**, **unionfs**,
|
||||
**aufs**, **DrivePool**, etc.](project_comparisons.md) Allowing for
|
||||
the aggregation of storage without the more rigid requirements and
|
||||
failure conditions of [RAID and other
|
||||
technologies](project_comparisons.md).
|
||||
**mergerfs** is a [union
|
||||
filesystem](https://en.wikipedia.org/wiki/Union_mount) that makes
|
||||
multiple storage devices or filesystems appear as a single unified
|
||||
directory. Built on [FUSE (Filesystem in
|
||||
Userspace)](https://en.wikipedia.org/wiki/Filesystem_in_Userspace), it
|
||||
is designed to simplify how you manage files across several
|
||||
independent filesystems without the complexity, fragility, or cost of
|
||||
RAID or similar storage aggregation technologies.
|
||||
|
||||
Think of mergerfs as a smart pooling layer: you can combine any number
|
||||
of [existing
|
||||
filesystems](faq/usage_and_functionality.md#can-mergerfs-be-used-with-filesystems-which-already-have-data)
|
||||
— whether they are on hard drives, SSDs, network shares, or other
|
||||
mounted storage — into what looks like one large filesystem, while
|
||||
still maintaining direct access to each individual filesystem. Unlike
|
||||
RAID, there's no rebuild process if a device fails. You only lose the
|
||||
files that were on that specific filesystem. You can also add or
|
||||
remove filesystems at any time without restructuring your entire pool.
|
||||
|
||||
mergerfs excels at cost-effective storage expansion, making it ideal
|
||||
for media libraries, backups, archival data, and other write-sometimes,
|
||||
read-often workloads where you need lots of space but don't want
|
||||
the overhead of traditional storage technologies.
|
||||
|
||||
**Key advantages:**
|
||||
|
||||
* Mix and match filesystems of any size, type, or underlying device
|
||||
* No parity calculations or rebuild times
|
||||
* Add or remove filesystems on the fly
|
||||
* Direct access to files on individual filesystems when needed
|
||||
* Flexible policies for controlling where new files are created
|
||||
|
||||
For users seeking alternatives to mhddfs, unionfs, aufs, or DrivePool,
|
||||
mergerfs offers a mature, actively maintained solution with extensive
|
||||
configuration options and documentation. See the [project comparisons
|
||||
for more comparisons.](project_comparisons.md)
|
||||
|
||||
|
||||
## Features
|
||||
@@ -19,7 +46,7 @@ technologies](project_comparisons.md).
|
||||
* Ability to add or remove filesystems/paths without impacting the
|
||||
rest of the data
|
||||
* Unaffected by individual filesystem failure
|
||||
* Configurable file selection and creation placement
|
||||
* Configurable file creation placement
|
||||
* File IO [passthrough](config/passthrough.md) for near native IO
|
||||
performance (where supported)
|
||||
* Works with filesystems of any size
|
||||
@@ -28,7 +55,7 @@ technologies](project_comparisons.md).
|
||||
* Ignore read-only filesystems when creating files
|
||||
* [Hard links](faq/technical_behavior_and_limitations.md#do-hard-links-work)
|
||||
* Hard link [copy-on-write / CoW](config/link-cow.md)
|
||||
* [Runtime configurable](runtime_interface.md)
|
||||
* [Runtime configurability](runtime_interface.md)
|
||||
* Support for extended attributes (xattrs)
|
||||
* Support for file attributes (chattr)
|
||||
* Support for POSIX ACLs
|
||||
@@ -36,12 +63,14 @@ technologies](project_comparisons.md).
|
||||
|
||||
## Non-features
|
||||
|
||||
* Read/write overlay on top of read-only filesystem like OverlayFS
|
||||
* File whiteout
|
||||
* RAID like redundancy (see [SnapRAID](https://www.snapraid.it) and
|
||||
[NonRAID](https://github.com/qvr/nonraid))
|
||||
* Redundancy
|
||||
* LVM/RAID style block device aggregation
|
||||
* Data integrity checks, snapshots, file versioning
|
||||
* Read/write overlays on top of read-only filesystems (like OverlayFS)
|
||||
* File whiteout
|
||||
* Splitting of files across branches
|
||||
* Active rebalancing of content
|
||||
|
||||
|
||||
## How it works
|
||||
@@ -62,7 +91,7 @@ For functions which change attributes or remove the file the behavior
|
||||
may be applied to all instances found.
|
||||
|
||||
The way in which mergerfs behaves is controlled by the
|
||||
[config/options/settings](config/options.md). More specifically by
|
||||
[config / options / settings](config/options.md). More specifically by
|
||||
[policies](config/functions_categories_policies.md).
|
||||
|
||||
|
||||
@@ -90,7 +119,6 @@ A + B = C
|
||||
+-- file7 +-- file7 +-- file7
|
||||
```
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
Head to the [quick start guide](quickstart.md).
|
||||
@@ -107,3 +135,6 @@ Head to the [quick start guide](quickstart.md).
|
||||
like something is not explained sufficiently or missing please [ask
|
||||
in one of the supported forums](support.md#contact-issue-submission)
|
||||
and the docs will be updated.
|
||||
* The search feature of MkDocs is not great. Searching for "literal
|
||||
strings" will generally not work. Alernative solutions are being
|
||||
investigated.
|
||||
|
||||
Reference in New Issue
Block a user