I spent some time this morning looking into this. Firstly, the
fs/direct-io.c code has moved on from what you were looking at
in test9 -- I've been testing using test11 this morning and the
code snippet you've pasted above is no longer the same (Andrews
comment above has modified - ENOTBLK is never returned now).
Secondly, I cannot reproduce the behaviour you've described --
direct IO into both unwritten and newly allocated extents works
correctly, and using your test case I got nice big 512k chunks
every time. There have been no changes in XFS in this area that
could have affected this, so I wonder what led you to suspect
the buffer was unmapped (your first "XXXXXX" above) originally?
Did you put a printk in there that was being triggered? (I did,
and it didn't, using -test11). I also put the printks into XFS
as I described in my previous mail, and we are definately giving
large IOs back to the generic direct IO code, for both cases -
pre-allocated and and not-pre-allocated cases.