On Mon, Jan 16, 2012 at 6:25 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
Thanks,> 0xffffffff81288b6a : xfs_aio_write_newsize_update+0x3a/0x90 [kernel]
Only ever taken when doing appending writes. Are you -sure- you are
not doing appending writes?
This is weird. Yes, I'm sure. I use pwrite() to write data to a 4G file, and I check the offset of each write and they are always smaller than 4G.
I instrument the code with systemtap and it shows me that ip->i_new_size and new_size in xfs_aio_write_newsize_update are both 0.
Since in my case there is only overwrite, ip->i_new_size will always be 0 (the only place that updates ip->i_new_size is xfs_file_aio_write_checks). Because of the same reason, new_size returned by xfs_file_aio_write_checks is always 0.
Is it what you expected?
> 0xffffffff812829f4 : __xfs_get_blocks+0x94/0x4a0 [kernel]
And for direct IO writes, this will be the block mapping lookup so
always hit.
What this says to me is that you are probably doing is lots of very
small concurrent write IOs, but I'm only guessing. Can you provide
your test case and a description of your test hardware so we can try
to reproduce the problem?
I build XFS on the top of ramdisk. So yes, there is a lot of small concurrent writes in a second.
I create a file of 4GB in XFS (the ramdisk has 5GB of space). My test program overwrites 4G of data to the file and each time writes a page of data randomly to the file. It's always overwriting, and no appending. The offset of each write is always aligned to the page size. There is no overlapping between writes.
So the test case is pretty simple and I think it's easy to reproduce it. It'll be great if you can try the test case.
Da
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
