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?
> 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?
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? 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.
cheers.
--
Nathan
|