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. Yan, Zheng -- 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