all - good conversation and again, thanks for digging into this. The comment about me running on an older kernel seems to be the problem and by rerunning my test on precise/3.5.0-23-generic all seems to be operating correctly, so I guess that was it.
However, the one thing that does jump out of this is that proc/fs/xsfstats and pcp were both showing many hundred MB/sec during tests that only ran for a few seconds, which is impossible so it still feels some like sort of accounting bug to me. On the other hand if the fact that this was an older kernel, and newer kernels are fine, perhaps it's something just to note and not worry about.
thanks again...
-mark
On Mon, Jun 17, 2013 at 1:41 AM, Nathan Scott <nathans@xxxxxxxxxx> wrote:
Hey Dave,
----- Original Message -----
> ...
> Must be an old version of RHEL6, because 6.4 doesn't do any IO at*nod* - RHEL6.3.
> all, same as upstream. This test workload is purely a metadata only
> workload (no data is written) and so it all gets gathered up by
> delayed logging.
> ...
> > I think it is still possible, FWIW. One could use python ctypes (as in
> > Marks test program) and achieve a page-aligned POSIX memalign,
>
> I wasn't aware you could get memalign() through python at all. I
> went looking for this exact solution a couple of month ago when
> these problems started to be reported and couldn't find anything
Yes, on reflection it doesn't jive too well with the way python wants
to do reads, in particular - os.read takes a file and a size, there's
no buffer exposed at the API level (for input).
It would need to be a separate python module to the core set I guess
(with a C component), and a slightly different API - or at least some
additional APIs which can take in an aligned buffer, rather than just
allocating one each time - but I believe it's still feasible.
cheers.
--
Nathan
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
