From: Jeff Liu <jeff.liu@oracle.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Mark Tinguely <tinguely@sgi.com>,
xfs@oss.sgi.com
Subject: Re: [PATCH v2 1/2] xfstests: introduce 279 for SEEK_DATA/SEEK_HOLE sanity check
Date: Fri, 10 Feb 2012 13:38:47 +0800 [thread overview]
Message-ID: <4F34AD67.8030000@oracle.com> (raw)
In-Reply-To: <20120210052046.GG12836@dastard>
On 02/10/2012 01:20 PM, Dave Chinner wrote:
> On Fri, Feb 10, 2012 at 11:24:26AM +0800, Jeff Liu wrote:
>> On 02/10/2012 06:25 AM, Dave Chinner wrote:
>>
>>> On Thu, Feb 09, 2012 at 10:27:05PM +0800, Jeff Liu wrote:
>>>> Strange, I also tried to build XFS with 2k which shown as following:
>>>>
>>>> $ sudo mkfs.xfs -b size=2k -n size=2k -f /dev/sda7
>>>>
>>>> $ xfs_info /dev/sda7
>>>> meta-data=/dev/sda7 isize=256 agcount=4, agsize=1418736 blks
>>>> = sectsz=512 attr=2
>>>> data = bsize=2048 blocks=5674944, imaxpct=25
>>> ^^^^^^^^^^
>>>
>>>> = sunit=0 swidth=0 blks
>>>> naming =version 2 bsize=2048 ascii-ci=0
>>> ^^^^^^^^^^
>>>
>>>> log =internal bsize=2048 blocks=5120, version=2
>>> ^^^^^^^^^^
>>> The block size for data, metadata, directories and the log is 2k,
>>> just like you asked.
>>
>> Sorry, I mislead you.
>>
>> Yes, the block size for data and metadata, etc are ok for me, but the
>> allocate unit at "struct stat.st_blksize" is 4k, It should match
>> data->bsize=2k IMHO.
>
> That field has nothing to do with the filesystem block size.
> According to the stat(2) man page:
>
> 'The st_blksize field gives the "preferred" blocksize for efficient
> file system I/O.'
>
> Giving a value of less than PAGE_SIZE for this field leads to
> inefficient IO because it forces the page cache to do
> read-modify-write cycles for single filesystem block writes. Hence
> on a 4k page size machine, it needs to report 4k as a minimum to
> avoid this. On a 64k page size machine, you'll find that value is
> 64k.
Sigh, I was misled by EXT4's output for stat(2), since its st_blksize is
2k which is equal to the mkfs formating value even on a 4k page size
machine. :(
>
> Indeed, XFS gives you some control over what is actually reported
> here. If your file lies on a real-time device, then XFS will export
> the extent allocation size (either the mkfs default of the per inode
> hint if it is set) in this field. For files on the data device, if
> you mount with the "largeio" mount option, XFS will export the
> stripe width if it is set, the biosize if that mount option is used
> or the PAGE_SIZE if neither are set. These are all different
> but valid definitions of "preferred blocksize for efficient IO".
>
> If you want to know the real block size of the filesystem, use
> statfs(2).
Definitely, thanks a lot!!
-Jeff
>
> Cheers,
>
> Dave.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2012-02-10 5:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-06 14:30 [PATCH v2 1/2] xfstests: introduce 279 for SEEK_DATA/SEEK_HOLE sanity check Jeff Liu
2012-02-08 5:42 ` Dave Chinner
2012-02-09 14:01 ` Jeff Liu
2012-02-09 14:27 ` Jeff Liu
2012-02-09 22:25 ` Dave Chinner
2012-02-10 3:24 ` Jeff Liu
2012-02-10 5:20 ` Dave Chinner
2012-02-10 5:38 ` Jeff Liu [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=4F34AD67.8030000@oracle.com \
--to=jeff.liu@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=tinguely@sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.