On Wed, May 12, 2010 at 01:02:07PM +0800, Yan, Zheng wrote:
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
On Mon, May 31, 2010 at 12:01 PM, Bruce Guenter br...@untroubled.org wrote:
On Wed, May 12, 2010 at 01:02:07PM +0800, Yan, Zheng wrote:
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
On Tue, Jun 1, 2010 at 3:01 AM, Bruce Guenter br...@untroubled.org wrote:
On Wed, May 12, 2010 at 01:02:07PM +0800, Yan, Zheng wrote:
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
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.
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
Hi.
When deleting a snapshot, I have observed that the disk space used by
that snapshot is not immediately released (according to statvfs or df).
Neither sync nor btrfs filesystem sync releases the disk space
neither. The only way I have found to actually fully release the disk
space is to issue
On Mon, May 10, 2010 at 12:23:52PM -0600, Bruce Guenter wrote:
Hi.
When deleting a snapshot, I have observed that the disk space used by
that snapshot is not immediately released (according to statvfs or df).
Neither sync nor btrfs filesystem sync releases the disk space
neither. The only