From: Dave Chinner <david@fromorbit.com>
To: Zhu Han <schumi.han@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: fallocate bug?
Date: Tue, 8 May 2012 15:47:03 +1000 [thread overview]
Message-ID: <20120508054703.GG5091@dastard> (raw)
In-Reply-To: <CAF7KpS906EpxfAMjzW1zx8fSdGacoxkg+Fz=P0Sb3yONMhe7gw@mail.gmail.com>
On Tue, May 08, 2012 at 01:10:55PM +0800, Zhu Han wrote:
> On Tue, May 8, 2012 at 12:40 PM, Dave Chinner <david@fromorbit.com> wrote:
> > On Tue, May 08, 2012 at 11:24:52AM +0800, Zhu Han wrote:
> > > On Tue, May 8, 2012 at 7:59 AM, Dave Chinner <david@fromorbit.com>
> > wrote:
> > > > And so now you've triggered the speculative delayed allocation
> > > > beyond EOF, which is normal behaviour. Hence there are currently
> > > > unused blocks beyond EOF which will get removed either when the next
> > > > close(fd) occurs on the file or the inode is removed from the cache.
> > > >
> > >
> > > Close(fd) should be invoked before dd quits. But why the extra blocks
> > > beyond EOF are not freed?
> >
> > The removal is conditional on how many times the fd has been closed
> > with dirty data on the inode.
> >
> > > The only way I found to remove the extra blocks is truncate the file to
> > its
> > > real size.
> >
> > If the close() didn't remove them, they will be removed when the
> > inode ages out of the cache. Why do you even care about them?
>
> Our distributed system depends on the real length of files to account the
> space usage.
That's ..... naive. It's never been valid to assume that the file
size is an accurate reflection of space usage, especially as it will
*always* be wrong for sparse files. In the same light, you also
cannot assume that it is an accurate reflection for non-sparse files
because we can do both explicit and speculative allocation beyond
EOF which only du will show. Not to mention that metadata is not
accounted in the file length, and that can consume a significant
amount of space, too.
> This behavior make the account inaccurate.
The block usage reported by XFS is both accurate and correct. The
file size reported by XFS is both accurate and correct. You're
"account inaccuracy" is assuming that they are the same. Perhaps you
should be using quotas for accurate space usage accounting?
Anyway, if you really want to stop speculative delayed allocation
beyond EOF, then use the allocsize mount option to control it.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-05-08 5:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-07 12:44 fallocate bug? Zhu Han
2012-05-07 23:59 ` Dave Chinner
2012-05-08 3:24 ` Zhu Han
2012-05-08 4:40 ` Dave Chinner
2012-05-08 5:10 ` Zhu Han
2012-05-08 5:47 ` Dave Chinner [this message]
2012-05-08 15:25 ` Zhu Han
2012-05-08 22:31 ` Dave Chinner
2012-05-09 1:43 ` Zhu Han
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=20120508054703.GG5091@dastard \
--to=david@fromorbit.com \
--cc=schumi.han@gmail.com \
--cc=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