Ext3 users - Sep 2002 - ext3 sync problem

Hi ext3 users:

Here I have a problem with how sync works on ext3. Basically I am using ext3
and GRUB on flash. What happens is:

1. ftp two big boot images into ext3 (on a flash)
2. do sync
3. reset immediately (without umounting)
4. GRUB cannot find the two images
5. boot with another image, and the two images are there (b/c journal was
replayed)

ext2 doesnt have this problem.

My first thinking was that ext3 sync doesn't sync all the data but probably
just the journal, but I asked ext3 maintainer and he said ext3 sync all the
data not just the journal, so I get confused.

Anyone has any idea why this is happening? Thanks.

Hua

Hi,

On Mon, Sep 16, 2002 at 10:07:30PM -0700, Hua Zhong wrote:
 
> Here I have a problem with how sync works on ext3. Basically I am using
ext3
> and GRUB on flash. What happens is:
> 
> 1. ftp two big boot images into ext3 (on a flash)
> 2. do sync
> 3. reset immediately (without umounting)
> 4. GRUB cannot find the two images
> 5. boot with another image, and the two images are there (b/c journal was
> replayed)
Yep.  sync() makes sure that the data is on the disk, but some of it
is still allowed to be in the journal at that point.  That means that
it's in the filesystem, but not where grub expects to find it.

I've already got a hack in ext3 to solve this for lilo --- whenever
ext3 gets a bmap() request (which asks us to return the absolute
location for the block on disk), if the file has been dirtied then it
flushes it out of the journal and onto permanent storage.
> My first thinking was that ext3 sync doesn't sync all the data but
probably
> just the journal, but I asked ext3 maintainer and he said ext3 sync all the
> data not just the journal, so I get confused.
It _does_ sync the data.  The problem is metadata.  The data is in the
right place but the inodes, indirect blocks and directory entries
which refer to that data are still in the journal.

Cheers,
 Stephen