github-mirror/mergerfs
2
0
Fork 0
mirror of https://github.com/trapexit/mergerfs.git synced 2024-11-25 09:41:43 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

Fix typos

Browse Source
This commit is contained in:
Andrea Gelmini 2020-07-20 13:01:33 +02:00
parent 468d42088a
commit 3a6738475a
4 changed files with 21 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
README.md
View File

@ -409,7 +409,7 @@ $ su -
# cd mergerfs
# tools/install-build-pkgs
# make rpm
# rpm -i rpmbuild/RPMS/<arch>/mergerfs-<verion>.<arch>.rpm
# rpm -i rpmbuild/RPMS/<arch>/mergerfs-<version>.<arch>.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?

20
man/mergerfs.1
View File

@ -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/<arch>/mergerfs\-<verion>.<arch>.rpm
#\ rpm\ \-i\ rpmbuild/RPMS/<arch>/mergerfs\-<version>.<arch>.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

2
src/fuse_ioctl.cpp
View File

@ -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/

2
src/option_parser.cpp
View File

@ -330,7 +330,7 @@ usage(void)
" default = libfuse\n"
" -o cache.writeback=<bool>\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=<bool>\n"
" Enable kernel caching of symlinks (if supported)\n"