All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.