the mv command performs a copy then delete operation when moving a file from one filesystem to another. in freebsd zfs datasets are handled as independent file systems even tho they share the same logical disk pool much like dynamic partitioning, if you would. for this given example I have a pool called array_0; array_0 has a total capacity of 4tb. I have two datasets on array_0; stor and public. stor has a folder FooBar which contains 3tb worth of files. mv array_0/stor/FooBar array_0/public/FooBar because these are different file systems it will copy then delete. here is the problem. there is only 1tb of space available on the pool. there isn't enough space for a full copy. today mv copied 1tb of data until the pool ran out of space then went kind of crazy. obviously it was not deleting files after it had already copied as it went along. if it had been deleting files as it was copying then it never would have totally consumed all disk space. Fix: delete individual files after they are copied during the mv How-To-Repeat: create a pool with two datasets create a some directory structure that represents 75% of total capacity. mv that folder from one dataset to another on the same pool.
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
Deletes / frees are lower priority than standard writes / reads so its quite possible in the scenario you describe that you could run out of space. Could you please confirm the exact behaviour by allow mv to process a number of files, before suspending and seeing if the free space is correct for the current progress after waiting for the pool to sync all outstanding requests. Regards Steve
Sorry, but I do not see any bug reported here. mv behaves as it is expected/documented to behave. ZFS behaves as it should as well. If the behavior is surprising to you then please update your knowledge of the tools. If you need a different behavior then you can script it yourself or use different tools to accomplish your job. -- Andriy Gapon
This is not a bug, it is a workflow problem introduced by the difference in b= ehavior between ZFS datasets and fixed sized file systems.=20 You should be able to move files from one dataset to another on the same poo= l without having to copy it to another pool and back. This all can be accomp= lished by deleting copied files more often than it currently does or at leas= t adding a flag to turn on synchronized deletes. After I am done testing the same scenario on Solaris I will run the test Ste= ve suggested.=20 Sent from my iPhone On Apr 20, 2013, at 3:12 PM, Andriy Gapon <avg@FreeBSD.org> wrote: >=20 > Sorry, but I do not see any bug reported here. > mv behaves as it is expected/documented to behave. > ZFS behaves as it should as well. > If the behavior is surprising to you then please update your knowledge of t= he tools. > If you need a different behavior then you can script it yourself or use > different tools to accomplish your job. >=20 > --=20 > Andriy Gapon
on 20/04/2013 22:49 Jon said the following: > This is not a bug, it is a workflow problem introduced by the difference in > behavior between ZFS datasets and fixed sized file systems. > > You should be able to move files from one dataset to another on the same pool > without having to copy it to another pool and back. You lost me at 'another pool'. Perhaps moving an object from one zfs dataset to another could be optimized, but... That would definitely require zfs-specific tools. It is not implemented in the code yet, as far as I know. > This all can be > accomplished by deleting copied files more often than it currently does or at > least adding a flag to turn on synchronized deletes. No, it can not be accomplished that way, because it would violate how mv(1) across filesystems works. Perhaps it's indeed the time to read the man page? > After I am done testing the same scenario on Solaris I will run the test > Steve suggested. Yes, please do. Personal experience is always more enlightening that someone else's words. > On Apr 20, 2013, at 3:12 PM, Andriy Gapon <avg@FreeBSD.org> wrote: > >> >> Sorry, but I do not see any bug reported here. mv behaves as it is >> expected/documented to behave. ZFS behaves as it should as well. If the >> behavior is surprising to you then please update your knowledge of the >> tools. If you need a different behavior then you can script it yourself or >> use different tools to accomplish your job. >> >> -- Andriy Gapon -- Andriy Gapon
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped