[Top] [All Lists]

Re: XFS capacity leak with dmapi

To: John Groves <John@xxxxxxxxxx>
Subject: Re: XFS capacity leak with dmapi
From: Vlad Apostolov <vapo@xxxxxxx>
Date: Thu, 12 Jul 2007 09:37:48 +1000
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <b062d32b0707111442r5050ce96w6ce75df451741f0@xxxxxxxxxxxxxx>
References: <b062d32b0707111442r5050ce96w6ce75df451741f0@xxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (X11/20070509)
John Groves wrote:
Vlad, I've tried to send this via linux-xfs, but for some reason my posts aren't going through (although I receive messages from it every day). Any ideas on this?

We have an application that uses DMAPI, and we've been chasing an XFS filesystem capacity leak for a week or two. Here is the scenario:

In some cases we initially create sparse files - normal open with O_CREAT and than an ftruncate to the desired size. If we subsequently fill the files via dm_write_invis(), and then remove/unlink the files, XFS does not appear to free up the capacity that was allocated when the file was made non-sparse via dm_write_invis(). Repeating this sequence enough times results in a full filesystem.

If we use write() to fill the file (after creating it as sparse), remove/unlink appears to work properly, and capacity does not appear to be leaked. We've seen this on several test systems; the current one is 2.6.22-rc4, which I think is current as to the SGI cvs tree (or very nearly so).

Can anybody shed light on this?

John Groves
Hi John,

I will investigate this problem but at the moment I can't immediately jump
on it. I am copying the email to linux-xfs list in case if someone could
answer it straightaway.


<Prev in Thread] Current Thread [Next in Thread>