[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: ext3 sync problem



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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]