From 74ed1b09eee2b950353b82bc22b2e35080e19a64 Mon Sep 17 00:00:00 2001 From: Antonio SJ Musumeci Date: Tue, 3 May 2016 11:44:04 -0400 Subject: [PATCH] faq update on direct writes --- README.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index a5ef9cda..de9af277 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ % mergerfs(1) mergerfs user manual % Antonio SJ Musumeci -% 2016-04-25 +% 2016-05-03 # NAME @@ -359,6 +359,10 @@ While aufs can offer better peak performance mergerfs offers more configurabilit A single drive failure will lead to full pool failure without additional redundancy. mergerfs performs a similar behavior without the catastrophic failure and lack of recovery. Drives can fail and all other data will continue to be accessable. +#### Can drives be written to directly? Outside of mergerfs while pooled? + +Yes. It will be represented immediately in the pool as the policies would describe. + #### It's mentioned that there are some security issues with mhddfs. What are they? How does mergerfs address them? [mhddfs](https://github.com/trapexit/mhddfs) tries to handle being run as **root** by calling [getuid()](https://github.com/trapexit/mhddfs/blob/cae96e6251dd91e2bdc24800b4a18a74044f6672/src/main.c#L319) and if it returns **0** then it will [chown](http://linux.die.net/man/1/chown) the file. Not only is that a race condition but it doesn't handle many other situations. Rather than attempting to simulate POSIX ACL behaviors the proper behavior is to use [seteuid](http://linux.die.net/man/2/seteuid) and [setegid](http://linux.die.net/man/2/setegid), become the user making the original call and perform the action as them. This is how [mergerfs](https://github.com/trapexit/mergerfs) handles things.