On 29/05/2015 20:06, Matthew Ahrens wrote: > On Fri, May 29, 2015 at 10:00 AM, Richard Yao <[email protected] > <mailto:[email protected]>> wrote: > > It seems that no one is particularly interested in a strict point in time > version, > > To be clear, I'm not saying that I'm uninterested in that, just that it seems > hard/complicated to achieve in combination with other requirements > (specifically, not needing to have the entire state in memory at once). (And > I > don't know that anyone else has weighed in.)
Additionally, what good is a consistent snapshot of the children if by the time you get it any number of changes might have happened. It's not like we are preventing the changes from happening while we look at or iterate the list. > so I'll drop that design constraint, document the issue and hope userland > programmers relying on the output will actually read the documentation > carefully so that they do not make the naive assumption that I imagine > that > they will make. > > > FWIW, userland programmers already need to be aware of these issues when > iterating over directory entries (e.g. if a file/directory is concurrently > renamed, "find" can list it 0, 1, or 2 times). Concurrent renames are pretty > difficult to deal with. -- Andriy Gapon _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
