From 468d42088a4d12a3d281ba13c0a5842461dd2b60 Mon Sep 17 00:00:00 2001 From: Andrea Gelmini Date: Mon, 20 Jul 2020 12:51:44 +0200 Subject: [PATCH 1/2] Removed duplicated include --- src/fs_base_fstatat.hpp | 1 - 1 file changed, 1 deletion(-) diff --git a/src/fs_base_fstatat.hpp b/src/fs_base_fstatat.hpp index 47c7ac77..5429c50a 100644 --- a/src/fs_base_fstatat.hpp +++ b/src/fs_base_fstatat.hpp @@ -22,7 +22,6 @@ #include #include #include -#include namespace fs { From 3a6738475a186ea023620f0ed2735e3250e09791 Mon Sep 17 00:00:00 2001 From: Andrea Gelmini Date: Mon, 20 Jul 2020 13:01:33 +0200 Subject: [PATCH 2/2] Fix typos --- README.md | 18 +++++++++--------- man/mergerfs.1 | 20 ++++++++++---------- src/fuse_ioctl.cpp | 2 +- src/option_parser.cpp | 2 +- 4 files changed, 21 insertions(+), 21 deletions(-) diff --git a/README.md b/README.md index 1581fd16..040eabd7 100644 --- a/README.md +++ b/README.md @@ -409,7 +409,7 @@ $ su - # cd mergerfs # tools/install-build-pkgs # make rpm -# rpm -i rpmbuild/RPMS//mergerfs-..rpm +# rpm -i rpmbuild/RPMS//mergerfs-..rpm ``` #### Generically @@ -799,7 +799,7 @@ $ dd if=/mnt/mergerfs/1GB.file of=/dev/null bs=1M count=1024 iflag=nocache conv= * If you don't see some directories and files you expect in a merged point or policies seem to skip drives be sure the user has permission to all the underlying directories. Use `mergerfs.fsck` to audit the drive for out of sync permissions. * Do **not** use `cache.files=off` (or `direct_io`) if you expect applications (such as rtorrent) to [mmap](http://linux.die.net/man/2/mmap) files. Shared mmap is not currently supported in FUSE w/ `direct_io` enabled. Enabling `dropcacheonclose` is recommended when `cache.files=partial|full|auto-full` or `direct_io=false`. * Since POSIX functions give only a singular error or success its difficult to determine the proper behavior when applying the function to multiple targets. **mergerfs** will return an error only if all attempts of an action fail. Any success will lead to a success returned. This means however that some odd situations may arise. -* [Kodi](http://kodi.tv), [Plex](http://plex.tv), [Subsonic](http://subsonic.org), etc. can use directory [mtime](http://linux.die.net/man/2/stat) to more efficiently determine whether to scan for new content rather than simply performing a full scan. If using the default **getattr** policy of **ff** its possible those programs will miss an update on account of it returning the first directory found's **stat** info and its a later directory on another mount which had the **mtime** recently updated. To fix this you will want to set **func.getattr=newest**. Remember though that this is just **stat**. If the file is later **open**'ed or **unlink**'ed and the policy is different for those then a completely different file or directory could be acted on. +* [Kodi](http://kodi.tv), [Plex](http://plex.tv), [Subsonic](http://subsonic.org), etc. can use directory [mtime](http://linux.die.net/man/2/stat) to more efficiently determine whether to scan for new content rather than simply performing a full scan. If using the default **getattr** policy of **ff** it's possible those programs will miss an update on account of it returning the first directory found's **stat** info and its a later directory on another mount which had the **mtime** recently updated. To fix this you will want to set **func.getattr=newest**. Remember though that this is just **stat**. If the file is later **open**'ed or **unlink**'ed and the policy is different for those then a completely different file or directory could be acted on. * Some policies mixed with some functions may result in strange behaviors. Not that some of these behaviors and race conditions couldn't happen outside **mergerfs** but that they are far more likely to occur on account of the attempt to merge together multiple sources of data which could be out of sync due to the different policies. * For consistency its generally best to set **category** wide policies rather than individual **func**'s. This will help limit the confusion of tools such as [rsync](http://linux.die.net/man/1/rsync). However, the flexibility is there if needed. @@ -936,7 +936,7 @@ First upgrade if possible, check the known bugs section, and contact trapexit. #### mergerfs appears to be crashing or exiting -There seems to be an issue with Linux version `4.9.0` and above in which an invalid message appears to be transmitted to libfuse (used by mergerfs) causing it to exit. No messages will be printed in any logs as its not a proper crash. Debugging of the issue is still ongoing and can be followed via the [fuse-devel thread](https://sourceforge.net/p/fuse/mailman/message/35662577). +There seems to be an issue with Linux version `4.9.0` and above in which an invalid message appears to be transmitted to libfuse (used by mergerfs) causing it to exit. No messages will be printed in any logs as it's not a proper crash. Debugging of the issue is still ongoing and can be followed via the [fuse-devel thread](https://sourceforge.net/p/fuse/mailman/message/35662577). #### mergerfs under heavy load and memory pressure leads to kernel panic @@ -1031,7 +1031,7 @@ Did you start with empty drives? Did you explicitly configure a `category.create The default create policy is `epmfs`. That is a path preserving algorithm. With such a policy for `mkdir` and `create` with a set of empty drives it will select only 1 drive when the first directory is created. Anything, files or directories, created in that first directory will be placed on the same branch because it is preserving paths. -This catches a lot of new users off guard but changing the default would break the setup for many existing users. If you do not care about path preservation and wish your files to be spread across all your drives change to `mfs` or similar policy as described above. If you do want path preservation you'll need to perform the manual act of creating paths on the drives you want the data to land on before transferring your data. Setting `func.mkdir=epall` can simplify managing path preservation for `create`. Or use `func.mkdir=rand` if you're intersted in just grouping together directory content by drive. +This catches a lot of new users off guard but changing the default would break the setup for many existing users. If you do not care about path preservation and wish your files to be spread across all your drives change to `mfs` or similar policy as described above. If you do want path preservation you'll need to perform the manual act of creating paths on the drives you want the data to land on before transferring your data. Setting `func.mkdir=epall` can simplify managing path preservation for `create`. Or use `func.mkdir=rand` if you're interested in just grouping together directory content by drive. #### Do hard links work? @@ -1115,7 +1115,7 @@ MergerFS is not intended to be a replacement for ZFS. MergerFS is intended to pr #### Why use mergerfs over UnRAID? -UnRAID is a full OS and its storage layer, as I understand, is proprietary and closed source. Users who have experience with both have said they perfer the flexibilty offered by mergerfs and for some the fact it is free and open source is important. +UnRAID is a full OS and its storage layer, as I understand, is proprietary and closed source. Users who have experience with both have said they prefer the flexibility offered by mergerfs and for some the fact it is free and open source is important. There are a number of UnRAID users who use mergerfs as well though I'm not entirely familiar with the use case. @@ -1131,7 +1131,7 @@ There are a number of UnRAID users who use mergerfs as well though I'm not entir #### Can drives be written to directly? Outside of mergerfs while pooled? -Yes, however its not recommended to use the same file from within the pool and from without at the same time (particularly writing). Especially if using caching of any kind (cache.files, cache.entry, cache.attr, cache.negative_entry, cache.symlinks, cache.readdir, etc.) as there could be a conflict between cached data and not. +Yes, however it's not recommended to use the same file from within the pool and from without at the same time (particularly writing). Especially if using caching of any kind (cache.files, cache.entry, cache.attr, cache.negative_entry, cache.symlinks, cache.readdir, etc.) as there could be a conflict between cached data and not. #### Why do I get an "out of space" / "no space left on device" / ENOSPC error even though there appears to be lots of space available? @@ -1144,7 +1144,7 @@ Due to path preservation, branch tagging, read-only status, and **minfreespace** It is also possible that the filesystem selected has run out of inodes. Use `df -i` to list the total and available inodes per filesystem. -If you don't care about path preservation then simply change the `create` policy to one which isn't. `mfs` is probably what most are looking for. The reason its not default is because it was originally set to `epmfs` and changing it now would change people's setup. Such a setting change will likely occur in mergerfs 3. +If you don't care about path preservation then simply change the `create` policy to one which isn't. `mfs` is probably what most are looking for. The reason it's not default is because it was originally set to `epmfs` and changing it now would change people's setup. Such a setting change will likely occur in mergerfs 3. #### Why does the total available space in mergerfs not equal outside? @@ -1174,10 +1174,10 @@ When file caching is enabled in any form (`cache.files!=off` or `direct_io=false To work around this situation mergerfs offers a few solutions. -1. Set `security_capability=false`. It will short curcuit any call and return `ENOATTR`. This still means though that mergerfs will receive the request before every write but at least it doesn't get passed through to the underlying filesystem. +1. Set `security_capability=false`. It will short circuit any call and return `ENOATTR`. This still means though that mergerfs will receive the request before every write but at least it doesn't get passed through to the underlying filesystem. 2. Set `xattr=noattr`. Same as above but applies to *all* calls to getxattr. Not just `security.capability`. This will not be cached by the kernel either but mergerfs' runtime config system will still function. 3. Set `xattr=nosys`. Results in mergerfs returning `ENOSYS` which *will* be cached by the kernel. No future xattr calls will be forwarded to mergerfs. The downside is that also means the xattr based config and query functionality won't work either. -4. Disable file caching. If you aren't using applications which use `mmap` it's probably simplier to just disable it all together. The kernel won't send the requests when caching is disabled. +4. Disable file caching. If you aren't using applications which use `mmap` it's probably simpler to just disable it all together. The kernel won't send the requests when caching is disabled. #### What are these .fuse_hidden files? diff --git a/man/mergerfs.1 b/man/mergerfs.1 index f44e089e..1ab48833 100644 --- a/man/mergerfs.1 +++ b/man/mergerfs.1 @@ -946,7 +946,7 @@ Remove the target from all drives with no source file Remove the source from all drives which failed to rename .RE .PP -The the removals are subject to normal entitlement checks. +The removals are subject to normal entitlement checks. .PP The above behavior will help minimize the likelihood of EXDEV being returned but it will still be possible. @@ -1011,7 +1011,7 @@ $\ su\ \- #\ cd\ mergerfs #\ tools/install\-build\-pkgs #\ make\ rpm -#\ rpm\ \-i\ rpmbuild/RPMS//mergerfs\-..rpm +#\ rpm\ \-i\ rpmbuild/RPMS//mergerfs\-..rpm \f[] .fi .SS Generically @@ -2046,7 +2046,7 @@ trapexit. There seems to be an issue with Linux version \f[C]4.9.0\f[] and above in which an invalid message appears to be transmitted to libfuse (used by mergerfs) causing it to exit. -No messages will be printed in any logs as its not a proper crash. +No messages will be printed in any logs as it's not a proper crash. Debugging of the issue is still ongoing and can be followed via the fuse\-devel thread (https://sourceforge.net/p/fuse/mailman/message/35662577). @@ -2198,7 +2198,7 @@ act of creating paths on the drives you want the data to land on before transferring your data. Setting \f[C]func.mkdir=epall\f[] can simplify managing path preservation for \f[C]create\f[]. -Or use \f[C]func.mkdir=rand\f[] if you\[aq]re intersted in just grouping +Or use \f[C]func.mkdir=rand\f[] if you\[aq]re interested in just grouping together directory content by drive. .SS Do hard links work? .PP @@ -2281,7 +2281,7 @@ Longer term the plan is to rewrite mergerfs to use the low level API. See above first. .PP If/when mergerfs is rewritten to use the low\-level API then it\[aq]ll -be plausible to support system libfuse but till then its simply too much +be plausible to support system libfuse but till then it's simply too much work to manage the differences across the versions. .SS Why use mergerfs over mhddfs? .PP @@ -2342,7 +2342,7 @@ here (https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSWhyNoRealReshaping). .PP UnRAID is a full OS and its storage layer, as I understand, is proprietary and closed source. -Users who have experience with both have said they perfer the flexibilty +Users who have experience with both have said they prefer the flexibility offered by mergerfs and for some the fact it is free and open source is important. .PP @@ -2365,7 +2365,7 @@ If you need that kind of device performance aggregation or high availability you should stick with RAID. .SS Can drives be written to directly? Outside of mergerfs while pooled? .PP -Yes, however its not recommended to use the same file from within the +Yes, however it's not recommended to use the same file from within the pool and from without at the same time (particularly writing). Especially if using caching of any kind (cache.files, cache.entry, cache.attr, cache.negative_entry, cache.symlinks, cache.readdir, etc.) @@ -2403,7 +2403,7 @@ filesystem. If you don\[aq]t care about path preservation then simply change the \f[C]create\f[] policy to one which isn\[aq]t. \f[C]mfs\f[] is probably what most are looking for. -The reason its not default is because it was originally set to +The reason it's not default is because it was originally set to \f[C]epmfs\f[] and changing it now would change people\[aq]s setup. Such a setting change will likely occur in mergerfs 3. .SS Why does the total available space in mergerfs not equal outside? @@ -2442,7 +2442,7 @@ Unfortunately at this moment the kernel is not caching the response. To work around this situation mergerfs offers a few solutions. .IP "1." 3 Set \f[C]security_capability=false\f[]. -It will short curcuit any call and return \f[C]ENOATTR\f[]. +It will short circuit any call and return \f[C]ENOATTR\f[]. This still means though that mergerfs will receive the request before every write but at least it doesn\[aq]t get passed through to the underlying filesystem. @@ -2462,7 +2462,7 @@ functionality won\[aq]t work either. .IP "4." 3 Disable file caching. If you aren\[aq]t using applications which use \f[C]mmap\f[] it\[aq]s -probably simplier to just disable it all together. +probably simpler to just disable it all together. The kernel won\[aq]t send the requests when caching is disabled. .SS What are these .fuse_hidden files? .PP diff --git a/src/fuse_ioctl.cpp b/src/fuse_ioctl.cpp index 78a0ba77..858f6b63 100644 --- a/src/fuse_ioctl.cpp +++ b/src/fuse_ioctl.cpp @@ -78,7 +78,7 @@ typedef char IOCTL_BUF[4096]; I've modified the API to allow changing of the output buffer size. This fixes the issue on little endian systems because the lower 4 bytes are the same regardless of what the user - allocated. However, on big endian systems thats not the case and it + allocated. However, on big endian systems that's not the case and it is not possible to safely handle the situation. https://lwn.net/Articles/575846/ diff --git a/src/option_parser.cpp b/src/option_parser.cpp index b48463f0..96a778d3 100644 --- a/src/option_parser.cpp +++ b/src/option_parser.cpp @@ -330,7 +330,7 @@ usage(void) " default = libfuse\n" " -o cache.writeback=\n" " Enable kernel writeback caching (if supported)\n" - " cache.files must must be enabled as well.\n" + " cache.files must be enabled as well.\n" " default = false\n" " -o cache.symlinks=\n" " Enable kernel caching of symlinks (if supported)\n"