xfs
[Top] [All Lists]

Re: file data not flushed to disk by umount?

To: Nathan Scott <nathans@xxxxxxx>
Subject: Re: file data not flushed to disk by umount?
From: James Chapman <jchapman@xxxxxxxxxxx>
Date: Thu, 24 Mar 2005 09:30:09 +0000
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20050324004850.GC704@frodo>
References: <4241471D.3090103@xxxxxxxxxxx> <20050324004850.GC704@frodo>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
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


<Prev in Thread] Current Thread [Next in Thread>