XFS_IOC_RESVSP64 versus XFS_IOC_ALLOCSP64 with multiple threads

[Stewart Smith <stewart@mysql.com>]

[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]

I recently (finally) wrote my patch to use the xfsctl to get better
allocation for NDB disk data files (datafiles and undofiles).
patch at:
http://lists.mysql.com/commits/15088

This actually ends up giving us a rather nice speed boost in some of the
test suite runs.

The problem is:
- two cluster nodes on 1 host (in the case of the mysql-test-run script)
- each node has a complete copy of the database
- ALTER TABLESPACE ADD DATAFILE / ALTER LOGFILEGROUP ADD UNDOFILE
creates files on *both* nodes. We want to zero these out.
- files are opened with O_SYNC (IIRC)

The patch I committed uses XFS_IOC_RESVSP64 to allocate (unwritten)
extents and then posix_fallocate to zero out the file (the glibc
implementation of this call just writes zeros out).

Now, ideally it would be beneficial (and probably faster) to have XFS do
this in kernel. Asynchronously would be pretty cool too.. but hey :)

The reason we don't want unwritten extents is that NDB has some realtime
properties, and futzing about with extents and the like in the FS during
transactions isn't such a good idea.

So, this would lead me to try XFS_IOC_ALLOCSP64 - which doesn't have the
"unwritten extents" warning that RESVSP64 does. However, with the two
processes writing the files out, I get heavy fragmentation. Even with a
RESVSP followed by ALLOCSP I get the same result.

So it seems that ALLOCSP re-allocates extents (even if it doesn't have
to) and really doesn't give you much (didn't do too much timing to see
if it was any quicker).

Is this expected behaviour? (it wasn't for me)
-- 
Stewart Smith, Software Engineer
MySQL AB, www.mysql.com
Office: +14082136540 Ext: 6616
VoIP: 6616@sip.us.mysql.com
Mobile: +61 4 3 8844 332

Jumpstart your cluster:
http://www.mysql.com/consulting/packaged/cluster.html

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]