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

Re: Changing root journal data mode



On Thu, Sep 06, 2001 at 08:39:10PM +0100, Stephen C. Tweedie wrote:
> 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.
>

Great!

> > 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!
> 

Thank you.  It just seemed strange, I'm glad it was on purpose... ;)

Mike





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