On Thu, Mar 24, 2005 at 09:30:09AM +0000, James Chapman wrote:
> Nathan Scott wrote:
> >
> >So, if memory serves, XFS was merged into 2.4.26 -- is your
> >kernel one you've patched yourself? Have you tried a current
> >kernel.org or XFS CVS kernel?
>
> It was merged in 2.4.25 I think. The kernel comes from a chip vendor
> (the chip has an integral MIPS CPU). I've diff'd their sources against
> vanilla 2.4.25 and there are no changes in the fs/ tree.
Mhmm. What about mm/ ? I suggest trying a mainline kernel too,
to rule out their changes.
> Is it known to work in MIPS little endian configs?
I haven't ever used such a platform, no. There is no architecture
specific code in XFS though, fwiw.
> My fs/buffer.c is identical to vanilla 2.4.25.
Send it to me? (save me searching :) - thanks).
> I notice that the xfs code has some conditionally compiled debug trace.
> Where does the trace go if I compile it in?
It goes into internal ring buffers. Tools like KDB can be used
to dump them out and/or search through them.
> Since my original posting, I've added a few printk's and can see that
> xfs is trying to flush data to disk, calling _pagebuf_page_io() and
> generic_make_request() for the inode of my test file. The
> pagebuf_iodone() callback is happening too.
Thats metadata IO. The regular file IO path goes through the code
in xfs_lrw.c and xfs_aops.c - particularly the xfs_aops.c writepage
function is likely to be of interest here, thats the one that deals
with flushing a page which has delayed allocate buffers attached.
cheers.
--
Nathan
|