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

Reply via email to