Hi All: Sorry for a late reply - I was busy with other things. I coded up a tiny module that does what you suggested to flush the journal and it worked like a charm. Thanks a lot for the hint. My only remaining question is that: if I do a journal_flush(), do I need to do a normal sync() as well to make sure all the meta data and data are synced to disk? My limited test shows that I don't need to, but I just want to be sure. I assume it saves the work to sync to the journal on disk. From my understanding: 1) sync: mem -> disk (journal) 2) journal_flush: mem-> disk (real data). Thanks. > -----Original Message----- > From: Theodore Ts'o [mailto:tytso@mit.edu] > Sent: Wednesday, September 18, 2002 12:19 PM > To: Hua Zhong > Cc: Andreas Dilger; Stephen C. Tweedie; ext3-users@redhat.com > Subject: Re: ext3 sync problem > > > On Tue, Sep 17, 2002 at 03:24:31PM -0700, Hua Zhong wrote: > > > > I don't quite understand here. As I understand it the only interaction > > between lilo (and any bootloader) and the OS is lilo loads OS > and that's it. > > What do you mean by "lilo calls FIBMAP ioctl"? > > > > When installing a new kernel, you have to run "/sbin/lilo" so the > location of the blocks on disk stored in the LILO boot blocks. > (Unlike GRUB, LILO doesn't read the filesystem at boot time; instead > it uses the FIBMAP ioctl to discover the locations on disk used by the > kernel, and stores that in a location where the LILO boot-time code > can find it.) > > > > It depends on what you mean, precisely. The metadata is > "synced" to the > > > journal. The problem is really that GRUB is ignoring the > fact that the > > > journal exists. If the kernel were to mount the filesystem, or e2fsck > > > run on it, then the metadata in the journal would be flushed to disk. > > > > I mean sync everything to disk so GRUB can see the change after > reboot. It > > cannot be in the journal. > > The problem is that GRUB is violating the rules, in that it is looking > at a filesystem that has the "needs recovery" bit set (i.e., that > there is data in the journal which must be replayed before the > fileystem is considered valid). Most of the time, it gets lucky, in > that the parts of the filesystem it is interested in aren't affected > by the fact there is un-replayed data in the journal. But what it is > doing is definitely not according to Hoyle. > > What you want is a "flush journal" ioctl/operation, and that currently > doesn't exist, although it would be pretty trivial to code one up. > (it's basically a journal_lock_updates(), journal_flush(), > journal_unlock_updates() call.) > > > > You are probably far better off to use JFFS2 or similar - it is a > > > journaled filesystem explicitly designed for flash devices, so it does > > > wear leveling and such (otherwise the journal + superblock > will quickly > > > wear out part of the flash). > > Actually most modern flash hardware takes care of doing the wear > leveling automatically. Necessary, since so many flash memories are > used to store FAT filesystems (for example in digital cameras). > > - Ted _______________________________________________ Ext3-users@redhat.com https://listman.redhat.com/mailman/listinfo/ext3-users
