From: Vlad Apostolov <vapo@sgi.com>
To: linux-xfs@oss.sgi.com
Cc: John Groves <John@Groves.net>
Subject: Re: XFS capacity leak with dmapi
Date: Wed, 25 Jul 2007 09:45:05 +1000 [thread overview]
Message-ID: <46A68F01.5090707@sgi.com> (raw)
In-Reply-To: <b062d32b0707111643n940b3abp4ff3d57fa3499f72@mail.gmail.com>
Hi John,
I finally found time to look at this issue. I couldn't see
an obvious reason for it by code inspection and next I tried to
reproduce the problem. I ran this script for a night:
emu:/mnt/scratch1/test # cat ./test_invis_wr
#! /bin/sh
for i in `seq 1 $1`;
do
echo loop $i
stat -f /mnt/scratch1
for file in `seq 1 $2`;
do
xfs_io -f -c "truncate 10485760" $file
./write_invis -l 10485760 $file
done
for file in `seq 1 $2`;
do
rm $file
done
stat -f /mnt/scratch1
done
and I couldn't reproduce the problem. I am runing 2.6.22 kernel with
the latest XFS/DMAPI. The write_invis utility is from the oss xfs_cmds
source tree here:
http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/dmapi/src/common/cmd/write_invis.c?rev=1.11
Could you please provide more details about your test configuration
and a script that reproduces the problem.
Regards,
Vlad
John Groves wrote:
> Thanks Vlad! I'll watch the list for info...and bug you after a
> polite interval if nothing becomes apparent.
>
> Cheers,
> John
>
> ---------- Forwarded message ----------
> From: * Vlad Apostolov* <vapo@sgi.com <mailto:vapo@sgi.com>>
> Date: Jul 11, 2007 6:37 PM
> Subject: Re: XFS capacity leak with dmapi
> To: John Groves <John@groves.net <mailto:John@groves.net> >
> Cc: linux-xfs@oss.sgi.com <mailto:linux-xfs@oss.sgi.com>
>
> 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?
> >
> > Thanks,
> > 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.
>
> Regards,
> Vlad
>
prev parent reply other threads:[~2007-07-24 23:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <b062d32b0707111442r5050ce96w6ce75df451741f0@mail.gmail.com>
2007-07-11 23:37 ` XFS capacity leak with dmapi Vlad Apostolov
[not found] ` <b062d32b0707111643n940b3abp4ff3d57fa3499f72@mail.gmail.com>
2007-07-24 23:45 ` Vlad Apostolov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46A68F01.5090707@sgi.com \
--to=vapo@sgi.com \
--cc=John@Groves.net \
--cc=linux-xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox