linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <wang.yi59@zte.com.cn>
To: <david@fromorbit.com>
Cc: <djwong@kernel.org>, <linux-xfs@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <xue.zhihong@zte.com.cn>,
	<wang.liang82@zte.com.cn>, <cheng.lin130@zte.com.cn>
Subject: Re:[PATCH] xfs: getattr ignore blocks beyond eof
Date: Thu, 31 Mar 2022 16:32:07 +0800 (CST)	[thread overview]
Message-ID: <202203311632074775168@zte.com.cn> (raw)
In-Reply-To: <20220331053340.GE1544202@dread.disaster.area>

> We do not, and have not ever tried to, hide allocation or block
> usage artifacts from userspace because any application that depends
> on specific block allocation patterns or accounting from the
> filesystem is broken by design.
>
> Every filesystem accounts blocks differently, and more often than
> not the block count exposed to userspace also includes metadata
> blocks (extent maps, xattr blocks, etc) and it might multiple count
> other blocks (e.g. shared extents). Hence so you can't actually
> use it for anything useful in userspace except reporting how many
> blocks this file *might* use.
>
> If your application is dependent on block counts exactly matching
> the file data space for waht ever reason, then what speculative
> preallocation does is the least of your problems.
>

Thanks for your explaination.

Unfortunately, the app I'm using evaluates diskusage by querying
the changes of the backend filesystem (XFS) file before and after
the operation. Without giving up the benefits of preallocation, the
app's statistics will become obsolete and no chance to correct it
at a small cost, because of the silence reclaim of posteof blocks.
That is the app's problem.

Posteof blocks will be reclaimed sooner or later, it seems reasonable
to ignore them directly during query. This is my humble opinion in
this patch. At the query moment, it's not real, but it will become so
eventually. It's a speculative result for query.

  parent reply	other threads:[~2022-03-31  8:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-31  8:02 [PATCH] xfs: getattr ignore blocks beyond eof Yi Wang
2022-03-31  0:38 ` Darrick J. Wong
2022-03-31  3:28   ` wang.yi59
2022-03-31  5:33     ` [PATCH] " Dave Chinner
2022-03-31  5:48       ` Dave Chinner
2022-03-31  8:32       ` wang.yi59 [this message]
2022-03-31 21:21         ` Dave Chinner
2022-04-01  8:09           ` wang.yi59
2022-04-01 22:14             ` [PATCH] " Dave Chinner
2022-03-31  2:57 ` kernel test robot
2022-03-31  3:07 ` kernel test robot

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=202203311632074775168@zte.com.cn \
    --to=wang.yi59@zte.com.cn \
    --cc=cheng.lin130@zte.com.cn \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=wang.liang82@zte.com.cn \
    --cc=xue.zhihong@zte.com.cn \
    /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;
as well as URLs for NNTP newsgroup(s).