From: Andrea Arcangeli <andrea@suse.de>
To: Chris Wedgwood <cw@f00f.org>
Cc: Jens Axboe <axboe@suse.de>, Rogier Wolff <R.E.Wolff@BitWizard.nl>,
Linus Torvalds <torvalds@transmeta.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
volodya@mindspring.com, Alexander Viro <viro@math.psu.edu>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] SMP race in ext2 - metadata corruption.
Date: Sun, 6 May 2001 04:50:01 +0200 [thread overview]
Message-ID: <20010506045001.C22850@athlon.random> (raw)
In-Reply-To: <Pine.LNX.4.21.0105031017460.30346-100000@penguin.transmeta.com> <200105041140.NAA03391@cave.bitwizard.nl> <20010504135614.S16507@suse.de> <20010504172940.U3762@athlon.random> <20010505151808.A29451@metastasis.f00f.org> <20010506023723.A22850@athlon.random> <20010506141437.A31269@metastasis.f00f.org>
In-Reply-To: <20010506141437.A31269@metastasis.f00f.org>; from cw@f00f.org on Sun, May 06, 2001 at 02:14:37PM +1200
On Sun, May 06, 2001 at 02:14:37PM +1200, Chris Wedgwood wrote:
> You don't need block device for fsck, in fact some OS require you use
> character devices (e.g. Solaris).
Moving e2fsck into the kernel is a completly different matter than
caching the blockdevice accesses with pagecache instead of buffercache.
And even if you move e2fsck or reiserfsck into the kernel (you could
technically do that just now regardless of where the block_dev cache
lives) there will still be partd that wants to mmap the blockdevice to
get rid of part of the fat32 partition (right now it uses read/write of
course because buffer cache cannot be mapped in userspace), there will
still be mtools, not self caching dbms, od </dev/hda, dd of=/dev/hda
etc..etc..etc.. that makes block_dev still *very* useful.
> I'm not saying we don't need block devices, but I really don't see
> much of a use for them once everything in in the page cache... I
> assume this is why others have got rid of them completely.
I have no idea why/if other got rid of it completly, but the fact block_dev
is useful has nothing to do if it's in pagecache or in buffercache,
really. It's just that by doing it in pagecache you can mmap it as well
and it will provide overall better performance and it's probably cleaner
design. The only visible change is that you will be able to mmap a
blockdevice as well.
About a kernel based fsck Alexander told me he likes it, I personally
don't care about it that much because I believe there's not that much to
share at the source level, fsck and real fs are quite different
problems, and what can be shared can be copied and by not sharing we get
the flexibility of not breaking fsck every time we change the kernel and
more in general the flexibility of doing it in userspace, sharing such
bytecode at runtime definitely doesn't matter. It also partly depends
from the fs but current ext2 situation is really fine to me and I
wouldn't consier a wortwhile project to move e2fsck into the kernel.
Andrea
next prev parent reply other threads:[~2001-05-06 2:50 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-26 15:45 [PATCH] SMP race in ext2 - metadata corruption Alexander Viro
2001-04-26 18:12 ` Andrea Arcangeli
2001-04-26 18:24 ` Alexander Viro
2001-04-26 19:00 ` Chris Mason
2001-04-26 18:49 ` Linus Torvalds
2001-04-26 19:08 ` Alexander Viro
2001-04-26 19:17 ` Alexander Viro
2001-04-26 20:06 ` Andrea Arcangeli
2001-04-26 19:15 ` Andrea Arcangeli
2001-04-26 19:34 ` Alexander Viro
2001-04-26 19:44 ` Andrea Arcangeli
2001-04-26 19:55 ` Alexander Viro
2001-04-26 20:08 ` Linus Torvalds
2001-04-26 20:21 ` Andrea Arcangeli
2001-04-26 20:49 ` Alexander Viro
2001-04-26 21:07 ` Andrea Arcangeli
2001-04-26 23:25 ` Alexander Viro
2001-04-27 0:05 ` Andrea Arcangeli
2001-04-27 0:19 ` Linus Torvalds
2001-04-27 0:35 ` Andrea Arcangeli
2001-04-26 21:13 ` Andrzej Krzysztofowicz
2001-04-27 18:02 ` LA Walsh
2001-04-27 18:17 ` dek_ml
2001-04-27 7:58 ` Vojtech Pavlik
2001-04-27 13:23 ` Alexander Viro
2001-04-27 14:32 ` Ville Herva
2001-04-27 16:52 ` Linus Torvalds
2001-04-27 19:22 ` Shane Wegner
2001-04-28 4:55 ` Albert D. Cahalan
2001-04-28 10:05 ` Jens Axboe
2001-04-27 14:29 ` Andi Kleen
2001-05-03 6:23 ` volodya
2001-05-03 9:29 ` Alan Cox
2001-05-03 17:21 ` Linus Torvalds
2001-05-04 11:40 ` Rogier Wolff
2001-05-04 11:56 ` Jens Axboe
2001-05-04 15:29 ` Andrea Arcangeli
2001-05-04 17:40 ` Linus Torvalds
2001-05-05 3:18 ` Chris Wedgwood
2001-05-06 0:37 ` Andrea Arcangeli
2001-05-06 2:14 ` Chris Wedgwood
2001-05-06 2:50 ` Andrea Arcangeli [this message]
2001-05-06 3:00 ` Chris Wedgwood
2001-05-06 3:15 ` Alexander Viro
2001-05-06 3:32 ` Chris Wedgwood
2001-05-06 3:59 ` Alexander Viro
2001-05-06 12:47 ` Alan Cox
2001-05-06 19:46 ` Andreas Dilger
2001-05-06 20:58 ` Alan Cox
2001-05-07 4:08 ` Andreas Dilger
2001-05-07 18:42 ` Pavel Machek
2001-05-11 14:54 ` Daniel Phillips
2001-05-18 14:46 ` Stephen C. Tweedie
2001-05-11 20:00 ` Alexander Viro
2001-05-06 3:38 ` Andreas Dilger
2001-05-06 3:51 ` Andrea Arcangeli
2001-05-04 12:15 ` Marc SCHAEFER
2001-05-04 17:28 ` Linus Torvalds
2001-05-04 17:39 ` Alexander Viro
2001-05-04 17:55 ` Linus Torvalds
2001-05-04 18:29 ` Alexander Viro
2001-05-04 19:13 ` Linus Torvalds
2001-05-05 11:20 ` Albert D. Cahalan
2001-05-05 17:11 ` Alexander Viro
2001-05-04 18:20 ` Richard Gooch
2001-05-04 18:35 ` Alexander Viro
2001-05-04 18:49 ` Richard Gooch
2001-05-04 19:15 ` Alexander Viro
2001-05-04 19:36 ` Richard Gooch
2001-05-04 19:58 ` Alexander Viro
2001-05-04 20:04 ` Richard Gooch
2001-05-04 19:04 ` Jens Axboe
2001-05-05 13:52 ` Rogier Wolff
2001-05-05 18:12 ` Richard Gooch
2001-05-08 13:46 ` volodya
2001-05-09 10:30 ` Helge Hafting
2001-05-04 21:11 ` Alan Cox
2001-05-04 21:50 ` Linus Torvalds
2001-04-26 20:11 ` Andrea Arcangeli
2001-04-26 20:14 ` Andrea Arcangeli
2001-04-26 20:26 ` Linus Torvalds
2001-04-26 21:16 ` Andrea Arcangeli
2001-04-26 20:42 ` Richard B. Johnson
2001-04-26 20:55 ` Alexander Viro
2001-04-27 11:43 ` Richard B. Johnson
2001-04-26 19:39 ` Andrea Arcangeli
[not found] <Pine.LNX.4.21.0104270953280.2067-100000@penguin.transmeta.com>
2001-04-27 17:36 ` Jeff Garzik
[not found] ` <3AE9A69B.D11F0BBD@evision-ventures.com>
2001-04-28 8:31 ` Matthias Urlichs
2001-04-28 13:20 ` Olaf Titz
2001-04-30 8:47 ` Neil Conway
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=20010506045001.C22850@athlon.random \
--to=andrea@suse.de \
--cc=R.E.Wolff@BitWizard.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=axboe@suse.de \
--cc=cw@f00f.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
--cc=volodya@mindspring.com \
/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