summaryrefslogtreecommitdiff
path: root/system/unionfs-fuse/README
diff options
context:
space:
mode:
Diffstat (limited to 'system/unionfs-fuse/README')
-rw-r--r--system/unionfs-fuse/README17
1 files changed, 10 insertions, 7 deletions
diff --git a/system/unionfs-fuse/README b/system/unionfs-fuse/README
index f49b8ef95d..15eb5cc1bc 100644
--- a/system/unionfs-fuse/README
+++ b/system/unionfs-fuse/README
@@ -1,12 +1,15 @@
unionfs-fuse is a unionfs filesystem implementation using fuse.
-It is meant to be way more flexible than the current in-kernel unionfs solution.
+It is meant to be way more flexible than the current in-kernel unionfs
+solution.
Why choose this stuff?
- * The filesystem has to be mounted after the roots are mounted when using the standard module.
- With unionfs-fuse, you can mount the roots later and their contents will appear seamlesly
- * You get caching (provided by the underlying FUSE page cache) which speeds things up a lot for free
- * Advanced features like copy-on-write and more
+ * The filesystem has to be mounted after the roots are mounted when
+ using the standard module. With unionfs-fuse, you can mount the
+ roots later and their contents will appear seamlesly.
+ * You get caching (provided by the underlying FUSE page cache) which
+ speeds things up a lot for free.
+ * Advanced features like copy-on-write and more.
Why NOT choose it?
- * Compared to kernel-space solution we need lots of useless context switches which makes
- kernel-only solution clear speed-winner
+ * Compared to kernel-space solution we need lots of useless context
+ switches which makes a kernel-only solution clear speed-winner.