Re: Changing root journal data mode

["Stephen C. Tweedie" <sct redhat com>]

Hi,

On Thu, Sep 06, 2001 at 11:04:07AM -0700, Mike Fedyk wrote:

> > The kernel also uses the buffer cache when dealing with the
> > superblock.  There are still some cache aliasing problems --- the
> > kernel will read several superblock fields from the buffer cache and
> > store them in the internal ext2/3 superblock struct at times, mainly
> > to avoid constant byte-swapping when accessing those fields, but the
> > fields where that is done tend to be mostly readonly so if tune2fs
> > modifies a few bytes of the buffer-cache superblock, those values
> > won't be overwritten by the kernel.  They won't be *read* by the
> > kernel until next mount, but they will survive on disk.
> 
> Ok, great.  Was this true on 2.2 and 2.0 kernels also?

Yes.

> Were there any fields that the kernel didn't treat as read only?  I can
> imagine that the FS_CLEAN flag would be written...

Indeed, as well as things like the summary counts for free blocks and
inodes, but those don't get touched by tune2fs so there's no conflict.

> Also, I noticed that on 2.4.9-ac7 if I run tune2fs -l:
> 
>  tune2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
>  Filesystem volume name:   <none>
>  Last mounted on:          <not available>
>  Filesystem UUID:          f5719854-d253-4809-9504-84850c44a796
>  Filesystem magic number:  0xEF53
>  Filesystem revision #:    1 (dynamic)
>  Filesystem features:      has_journal filetype needs_recovery sparse_super
>  Filesystem state:         clean

> This is my root FS, and it is mounted, should this be clean?

If it's ext3, then yes, it should.  The ext3 journal has a separate
field which indicates whether journal recovery is required, but the
combination of (filesystem+journal) results in recovering a clean
filesystem.  That's why e2fsck will replay the journal at boot time
but won't force a full fsck.  Clearing the clean state would result in
a full fsck after a crash, which is obviously not what we want for a
journaling filesystem!

Cheers,
 Stephen