Re: file data not flushed to disk by umount?

[James Chapman <jchapman@xxxxxxxxxxx>]

Nathan Scott wrote:

> On Wed, Mar 23, 2005 at 10:38:21AM +0000, James Chapman wrote:
>
> > expected. However, if the filesystem is unmounted, data is not being
> > written to disk. The file exists but contains zeros. Shouldn't umount
> > flush any in-memory data to disk?
>
>
> I'd sure hope so. :)
>
>
> > bash-2.05b# mount -t xfs -o rtdev=/dev/hdc2 /dev/hdc1 /mnt/hd
> > XFS mounting filesystem ide1(22,1)
> > bash-2.05b# echo "Hello, world" > /mnt/hd/my-file
> > ...
> > bash-2.05b# umount /mnt/hd
> > bash-2.05b# mount /mnt/hd
> > ...
> > bash-2.05b# od -x /mnt/hd/my-file
> > 0000000 0000 0000 0000 0000 0000 0000 0000
> > 0000015
> >
> > The unwritten=1 in the above output is interesting...
>
>
> Hmm, not really, why do you say that?

Just that it implies some data that is unwritten (to disk). I'm not 
familiar with the inner workings of xfs so I shouldn't jump to conclusions.

> > The hardware platform is a custom embedded MIPS board, running kernel
> > 2.4.25 (MIPS little endian). Ext2 and ext3 filesystems work as
> > expected so the hardware is ok.
>
>
> 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.

> Needless to say, the above sequence of commands works on every
> kernel I've ever used with XFS, so I'd punt and say something
> went wrong when you patched your kernel?  

Is it known to work in MIPS little endian configs?

> Perhaps the BH_delay
> flag checks in fs/buffer.c were missed, and the generic code is
> not calling back into XFS correctly for delayed allocate buffers?
> Just a guess though.

My fs/buffer.c is identical to vanilla 2.4.25.

I notice that the xfs code has some conditionally compiled debug trace. 
Where does the trace go if I compile it in?

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.

Are there other things I can check? I'm familiar with several parts of 
the kernel implementation but not the filesystems. :)

Thanks for your help!

/james