On Thu, 2007-12-20 at 22:17 +0100, Mario Vukelic wrote:
> When ext3 was new, I am pretty certain that I have read quotes by
> Theodore T'so that he does not recommend turning off the checks. It's
> been a long time though, and searching now turns up nothing definitive
> for me.


Ah, I think I found an incomplete quote of what I had in mind. It's not
really conclusive, and I'd like to know that was edited out
anyway. http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html

"Q: If a system shutdown hard, even with journaling is it at all
necessary to run e2fsck?

Theodore Ts'o said:

It's best to just always run e2fsck. [...]
E2fsck will run the journal automatically, and if the filesystem is
otherwise clean, it skip doing a full filesystem check.
If the filesystem is not clean (because during the previous run the
kernel noticed some filesystem inconsistencies), e2fsck will
automatically do a full check if it is necessary.
If you have multiple disks, fsck will run multiple e2fsck processes in
parallel, thus speeding up your boot sequence than if you let the kernel
replay the journal for each filesystem when it tries to mount it, since
then the journal replays will be done sequentially, instead of in
parallel."

Here's Stephen Tweedie, he clearly states that no fsck is needed after a
dirty unmount, but I don't find anything on periodic scheduled checks
(which can be scheduled only on a server, not a personal computer). Is
Tweedie still at RedHat? If so it should be no problem to ask.
http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html

"And some of these EXT2 filesystems are getting really rather big. Even
24 months ago, there were people building 500 gigabyte EXT2 filesystems.
They take a long time to fsck. I mean, really. These are filesystems
that can take three or four hours just to mkfs. Doing a consistency
check on them is a serious down time. So the real objective in EXT3 was
this simple thing: availability. When something goes down in EXT3, we
don't want to have to go through a fsck. We want to be able to reboot
the machine instantly and have everything nice and consistent.

And that's all it does. It's a minimal extension to the existing EXT2
filesystem to add journaling. And it's really important, EXT2 is the
workhorse filesystem. It's the standard stable filesystem. We don't want
to turn EXT2 into an experimental filesystem. For one thing, users
expect to have EXT2 there as a demonstration of how to code filesystems
for Linux. It's a small, easily understood filesystem which demonstrates
how to do all of the talking to the page cache, which has changed in
2.4, all of the locking in the directory handling, which has changed in
2.4. All of these changes in the VFS interface and the VM interface that
filesystems have to deal with are showcased in EXT2. So there are
multiple reasons why we really do not want to start making EXT2 into an
experimental filesystem, adding all sorts of new destabilizing features.
And so the real goal for EXT3 was to provide the minimal changes
necessary to provide a complete journaling solution. [03m, 26s]

So it provides scaling of the disk filesystem size and it allows you to
make larger and larger filesystems without the fsck penalty."



-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Reply via email to