On 12 May 2010 06:02, Yan, Zheng <yanzh...@21cn.com> wrote: > On Tue, May 11, 2010 at 11:45 PM, Bruce Guenter <br...@untroubled.org> wrote: >> On Tue, May 11, 2010 at 08:10:38AM +0800, Yan, Zheng wrote: >>> This is because the snapshot deleting ioctl only removes the a link. >> >> Right, I understand that. That part is not unexpected, as it works just >> like unlink would. However... >> >>> The corresponding tree is dropped in the background by a kernel thread. >> >> The surprise is that 'sync', in any form I was able to try, does not >> wait until all or even most of the I/O is completed. Apparently the >> standards spec for sync(2) says it is not required to wait for I/O to >> complete, but AFAIK all other Linux FS do wait (the man page for sync(2) >> implies as much, as does the info page for sync in glibc). >> >> The only way I've found so far to force this behavior is to unmount, and >> that's rather intrusive to other users of the FS. >> >>> We could probably add another ioctl that waits until the tree has been >>> completely dropped. >> >> Since the expected behavior for sync is to wait until all pending I/O >> has been completed, I would argue this should be the default action for >> sync. Am I misunderstanding something? >> > > Dropping a tree can be lengthy. It's not good to let sync wait for hours. > For most linux FS, 'sync' just force an transaction/journal commit. I don't > think they wait for large operations that can span multiple transactions to > complete.
Disclaimer: I know nothing about the internals of Btrfs! I have an analogy as a way to thinking about what deleting a snapshot entails (which I hope isn't totally bogus). Deleting a clone of a file system is not like unlinking a single file. It is analogous to deleting a directory tree. Syncing in the middle of a recursive delete will wait for the in flight I/O to complete, but it would not wait for the unlink requests from the portion of the directory tree not yet traversed. The same would be true when the kernel thread deletes the snapshot by recursing through it's tree. Mike -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
