linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Castle <dalgoda@ix.netcom.com>
To: kernel list <linux-kernel@vger.kernel.org>
Subject: Re: 2.4.14 still not making fs dirty when it should
Date: Thu, 29 Nov 2001 12:35:22 -0800	[thread overview]
Message-ID: <20011129123522.G7992@thune.mrc-home.com> (raw)
In-Reply-To: <20011128231504.A26510@elf.ucw.cz> <3C069291.82E205F1@zip.com.au>, <3C069291.82E205F1@zip.com.au> <20011129120826.F7992@thune.mrc-home.com> <3C069919.E679F1F8@zip.com.au>
In-Reply-To: <3C069919.E679F1F8@zip.com.au>

On Thu, Nov 29, 2001 at 12:22:49PM -0800, Andrew Morton wrote:
> What happens is that the superblock is altered in-memory
> to say "the filesystem needs checking", but it's not written
> out to disk.
> 
> So other things can come in, alter the fs, get written out *before*
> the superblock and then you crash.  fsck won't be run, and the
> filesystem is left in an inconsistent state.

Ok.  I could see this being a bad thing.

I could also see the easiest thing to implement would be updating the super
block on mount.

However, is this a case where Linux tries not to update the superblock
about being dirty until something has actually changed (ie, be slightly
smarter), and that's not working, or is the superblock simply not being
updated on mount?

Thanks,
mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

  reply	other threads:[~2001-11-29 20:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-28 22:15 2.4.14 still not making fs dirty when it should Pavel Machek
2001-11-29 19:54 ` Andrew Morton
2001-11-29 20:08   ` Mike Castle
2001-11-29 20:22     ` Andrew Morton
2001-11-29 20:35       ` Mike Castle [this message]
2001-11-29 20:41         ` Andrew Morton
2001-11-29 21:12       ` Andreas Dilger
2001-11-30  8:00         ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20011129123522.G7992@thune.mrc-home.com \
    --to=dalgoda@ix.netcom.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).