linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luigi Genoni <kernel@Expansa.sns.it>
To: Rogier Wolff <R.E.Wolff@BitWizard.nl>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, <otto.wyss@bluewin.ch>,
	<linux-kernel@vger.kernel.org>
Subject: Re: How errorproof is ext2 fs?
Date: Sun, 16 Sep 2001 12:14:25 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.33.0109161205210.20434-100000@Expansa.sns.it> (raw)
In-Reply-To: <200109160858.KAA28624@cave.bitwizard.nl>



On Sun, 16 Sep 2001, Rogier Wolff wrote:

> Alan Cox wrote:
> > > due to an not responding USB-keyboard/-mouse (what a nice coincident). Now while
> > > the Mac restarted without any fuse I had to fix the ext2-fs manually for about
> > > 15 min. Luckily it seems I haven't lost anything on both system.
> > >
> > > This leaves me a bad taste of Linux in my mouth. Does ext2 fs really behave so
> > > worse in case of a crash? Okay Linux does not crash that often as MacOS does, so
>
> > That sounds like it behaved well. fsck didnt have enough info to safely
> > do all the fixup without asking you. Its not a reliability issue as such.
>
> Well, fsck wants to ask
>
> 	"Found an unattached inode, connect to lost+found?"
>
> to the user and will interrupt an automatic reboot for that.
>
> This is bad: The safe choice is safe: It won't cause data-loss.
>
> Maybe it should report it (say by Email), but interrupting a reboot
> just for connecting a couple of files to lost+found, that's
> rediculous.
>
> If it would give me enough information when I do this manually, I'd
> make an informed decision. However, what are the chances of me knowing
> that inode 123456 is a staroffice bak-file? So the only way to safely
> operate is to link them into lost+found, and then to look at the files
> manually.
>
That is the right way a block based FS non journaled should act in a Unix
system. Basically fsck can see inode numbers, not file names.
That is also the way UFS acts, and belive me, older UFS versions were
mutch more prone to corruptions and crashes (Solaris 8 UFS seems t make
journaling of part of meta-data, but I am not sure). In front of UFS ext2
is more than rock solid. Unattached i-nodes are just something that can
happen for this kind of filesystems.

If you want a different behaviour, like for sure many others suggested, go
to a journaled filesystem. It seems to me that you would need a filesystem
that would make journaling of both meta-data and data like ext3 or jfs,
(actually reiserFS journals just metadata)

Luigi


  parent reply	other threads:[~2001-09-16 10:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-13 21:30 How errorproof is ext2 fs? Otto Wyss
2001-09-13 21:53 ` Joel Jaeggli
2001-09-13 22:05 ` Alan Cox
2001-09-14 19:16   ` Otto Wyss
2001-09-14 20:39     ` Mike Fedyk
2001-09-16  8:58   ` Rogier Wolff
2001-09-16 10:00     ` Frank Schneider
2001-09-16 10:14     ` Luigi Genoni [this message]
     [not found] ` <3BA1E670.9010300@foogod.com>
2001-09-14 20:37   ` Otto Wyss
2001-09-14 23:09     ` Alan Cox
2001-09-14 13:09 Jesse Pollard
     [not found] <Pine.LNX.4.10.10109140953100.24181-100000@coffee.psychology.mcmaster.ca>
2001-09-14 20:47 ` Otto Wyss
2001-09-14 21:38   ` Andreas Dilger
2001-09-15  6:39 Timothy A. Seufert

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=Pine.LNX.4.33.0109161205210.20434-100000@Expansa.sns.it \
    --to=kernel@expansa.sns.it \
    --cc=R.E.Wolff@BitWizard.nl \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=otto.wyss@bluewin.ch \
    /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).