Merge pull request #550 from trapexit/mv_warning

mention mv quirk in known issues
This commit is contained in:
trapexit 2019-01-06 13:24:51 -05:00 committed by GitHub
commit 8686eadcf4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 44 additions and 0 deletions

View File

@ -533,6 +533,24 @@ The reason this is the default is because any other policy would be far more exp
If you always want the directory information from the one with the most recent mtime then use the `newest` policy for `getattr`. If you always want the directory information from the one with the most recent mtime then use the `newest` policy for `getattr`.
#### `mv /mnt/pool/foo /mnt/disk1/foo` removes `foo`
This is not a bug.
Run in verbose mode to better undertand what's happening: `mv -v /mnt/pool/foo /mnt/disk1/foo`
```
$ mv -v /mnt/pool/foo /mnt/disk1/foo
copied '/mnt/pool/foo' -> '/mnt/disk1/foo'
removed '/mnt/pool/foo'
$ ls /mnt/pool/foo
ls: cannot access '/mnt/pool/foo': No such file or directory
```
`mv`, when working across devices, is copying the source to target and then removing the source. Since the source **is** the target in this case, depending on the unlink policy, it will remove the just copied file and other files across the branches.
If you want to move files to one drive just copy them there and use mergerfs.dedup to clean up the old paths or manually remove them from the branches directly.
#### cached memory appears greater than it should be #### cached memory appears greater than it should be
Use the `direct_io` option as described above. Due to what mergerfs is doing there ends up being two caches of a file under normal usage. One from the underlying filesystem and one from mergerfs. Enabling `direct_io` removes the mergerfs cache. This saves on memory but means the kernel needs to communicate with mergerfs more often and can therefore result in slower speeds. Use the `direct_io` option as described above. Due to what mergerfs is doing there ends up being two caches of a file under normal usage. One from the underlying filesystem and one from mergerfs. Enabling `direct_io` removes the mergerfs cache. This saves on memory but means the kernel needs to communicate with mergerfs more often and can therefore result in slower speeds.

View File

@ -1140,6 +1140,32 @@ possibly spin up sleeping drives.
.PP .PP
If you always want the directory information from the one with the most If you always want the directory information from the one with the most
recent mtime then use the \f[C]newest\f[] policy for \f[C]getattr\f[]. recent mtime then use the \f[C]newest\f[] policy for \f[C]getattr\f[].
.SS \f[C]mv\ /mnt/pool/foo\ /mnt/disk1/foo\f[] removes \f[C]foo\f[]
.PP
This is not a bug.
.PP
Run in verbose mode to better undertand what\[aq]s happening:
\f[C]mv\ \-v\ /mnt/pool/foo\ /mnt/disk1/foo\f[]
.IP
.nf
\f[C]
$\ mv\ \-v\ /mnt/pool/foo\ /mnt/disk1/foo
copied\ \[aq]/mnt/pool/foo\[aq]\ \->\ \[aq]/mnt/disk1/foo\[aq]
removed\ \[aq]/mnt/pool/foo\[aq]
$\ ls\ /mnt/pool/foo
ls:\ cannot\ access\ \[aq]/mnt/pool/foo\[aq]:\ No\ such\ file\ or\ directory
\f[]
.fi
.PP
\f[C]mv\f[], when working across devices, is copying the source to
target and then removing the source.
Since the source \f[B]is\f[] the target in this case then when the
remove happens it can, depending on the unlink policy, remove the just
copied file and other files across the branches.
.PP
If you want to move files to one drive just copy them there and use
mergerfs.dedup to clean up the old paths or manually remove them from
the branches directly.
.SS cached memory appears greater than it should be .SS cached memory appears greater than it should be
.PP .PP
Use the \f[C]direct_io\f[] option as described above. Use the \f[C]direct_io\f[] option as described above.