From: Hans Reiser <reiser@namesys.com>
To: Andreas Dilger <adilger@clusterfs.com>
Cc: Oleg Drokin <green@namesys.com>,
Zygo Blaxell <eazgwmir@umail.furryterror.org>,
reiserfs-list@namesys.com
Subject: Re: Corrupted/unreadable journal: reiser vs. ext3
Date: Tue, 18 Feb 2003 21:21:54 +0300 [thread overview]
Message-ID: <3E5279C2.3090702@namesys.com> (raw)
In-Reply-To: <20030215153710.A1723@schatzie.adilger.int>
Andreas Dilger wrote:
>On Feb 14, 2003 22:19 +0300, Hans Reiser wrote:
>
>
>>Andreas Dilger wrote:
>>
>>
>>>You are well aware
>>>that the e2fsck check intervals can be tuned per-filesystem and even
>>>disabled if desired (it prints options for how to do this at mke2fs time
>>>and is clearly documented for the experienced user). For a boot-once-a-day
>>>machine, the default is to check about once a month (at most 6 months for
>>>the time check), and if machines are crashing more often, then they should
>>>probably be checked more often because _something_ has to be causing crashes.
>>>
>>>
>>>
>>The idea that how often you boot determines how often it checks is just
>>silly, sorry.
>>
>>
>
>I guess the shortcoming in the ext2 case is that it counts mounts and
>not crashes. If it were counting the number of times the filesystem
>was uncleanly shut down instead of normal shutdowns, would that be more
>acceptable? The reason I'm still interested in crashes, even if they
>are not filesystem-related crashes, is because there had to be _something_
>which caused a crash (bad code, bad hardware, whatever), and once you have
>any driver corrupting memory the chance that it is also corrupting filesystem
>memory exists.
>
This is at least arguably legitimate;-)....
>
>
>
>>>Having reiserfsck just do read-only checks shouldn't force you to type
>>>"yes" (and we mean "yes" because this is so scary, mere mortals shouldn't
>>>be doing this). Hans, you've always talked about making things easy for
>>>the average user (error messages and such), don't you think that making
>>>a data consistency check for the user a little less intimidating too?
>>>
>>>
>>I think that you should have to agree that you have time to wait for
>>fsck before you get stuck with a 1 day large server fsck.
>>
>>
>
>That is definitely true. However, my assumption would be that if someone
>is running a system with terabytes of data they will read the man page
>after waiting a day for fsck to complete, or lose their job.
>
How much does a terabyte of disk cost? A thousand dollars? How much
does a qualified sysadmin cost? $100-200k in Silicon Valley (but
rapidly reducing).
Yet this is still the wrong attitude.... our job is to make the
software so that it works without hassle. They don't need more items
on their checklists, they need software that manages the checklists for
them.
Also, whether a sysadmin is willing to wait a day for fsck might depend
on the day you ask him.
So I completely reject the argument you make.
> It is entirely
>possible for administrators to disable the per-mount e2fsck checking, and
>the time-based (6 months by default) checking too, and do fsck themselves.
>My experience would be that, like backups, people don't do that, so leaving
>the 6 month check in protects users from themselves.
>
Most users don't know that they can do it, and those that do don't need
us giving them more things they need to set when installing the OS.
>
>The other thing to keep in mind is that you can have different "levels" of
>automated fsck at boot time, depending on how long they take. You never
>necessarily have to try and fix anything with "fsck -a", just detect errors
>and leave it up to the user to decide what to do if you find a problem:
>- always recover journal, validate superblock, error flag (< 1s)
>
>Don't know how long it takes these things to run, so it is up to you to
>trade off checks vs. speed, and you could even round-robin them (storing
>the last checked item in the superblock or something):
>- check block allocation bitmaps match superblock counts
>- walk directory structure from root, checking for directory corruption
>- check btree validity on inodes for up to 10 seconds (or whatever, storing
> last checked inode in superblock for restarting this test at next one)
>
>By all means, don't do checks for an hour, or allow users to set the maximum
>boot check duration in the superblock. I'm sure users don't mind waiting
>5s at boot time if it means they don't lose data.
>
I doubt that there is a lot we can check in 5 seconds on a filesystem
with lots of small files, but I could be wrong.
>
>Cheers, Andreas
>--
>Andreas Dilger
>http://sourceforge.net/projects/ext2resize/
>http://www-mddsp.enel.ucalgary.ca/People/adilger/
>
>
>
>
>
--
Hans
next prev parent reply other threads:[~2003-02-18 18:21 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-12 20:05 Corrupted/unreadable journal: reiser vs. ext3 Dirk Schenkewitz
2003-02-13 22:49 ` Zygo Blaxell
2003-02-14 0:32 ` Hans Reiser
2003-02-14 8:18 ` Oleg Drokin
2003-02-14 10:13 ` Andreas Dilger
2003-02-14 10:17 ` Oleg Drokin
2003-02-14 10:50 ` Andreas Dilger
2003-02-14 10:59 ` Oleg Drokin
2003-02-14 13:34 ` Hans Reiser
2003-02-14 16:04 ` Rudy Zijlstra
2003-02-14 19:06 ` Andreas Dilger
2003-02-14 19:19 ` Hans Reiser
2003-02-15 12:51 ` Vitaly Fertman
2003-02-15 13:00 ` Vitaly Fertman
2003-02-18 19:50 ` Hans Reiser
2003-02-18 20:05 ` Vitaly Fertman
2003-02-18 22:18 ` Hans Reiser
2003-02-15 13:04 ` Anders Widman
2003-02-15 13:23 ` Oleg Drokin
2003-02-17 19:43 ` Hans Reiser
2003-02-17 23:35 ` Error <-> Partition Correspondance [was Re: Corrupted/unreadable journal: reiser vs. ext3] Manuel Krause
2003-02-18 6:54 ` Oleg Drokin
2003-02-21 7:27 ` Manuel Krause
[not found] ` <20030221103757.B28866@namesys.com>
2003-02-21 8:22 ` reiserfs messages cleanup patch Manuel Krause
2003-02-21 8:32 ` Oleg Drokin
2003-02-15 22:37 ` Corrupted/unreadable journal: reiser vs. ext3 Andreas Dilger
2003-02-18 7:04 ` fsck on boot (was: Re: Corrupted/unreadable journal: reiser vs. ext3) Ookhoi
2003-02-18 18:21 ` Hans Reiser [this message]
2003-02-18 19:22 ` Corrupted/unreadable journal: reiser vs. ext3 Oleg Drokin
2003-02-18 19:28 ` Hans Reiser
2003-02-18 21:17 ` Valdis.Kletnieks
2003-02-18 22:02 ` Matthias Andree
2003-02-19 6:26 ` Oleg Drokin
2003-02-18 22:23 ` Hans Reiser
-- strict thread matches above, loose matches on Subject: below --
2003-02-20 9:55 Dirk Schenkewitz
2003-02-20 10:20 ` Anders Widman
2003-02-17 10:04 Dirk Schenkewitz
2003-02-20 1:27 ` Juan Quintela
2003-02-20 9:03 ` Anders Widman
2003-02-14 14:30 Dirk Schenkewitz
2003-02-14 14:20 Dirk Schenkewitz
2003-02-14 20:58 ` Valdis.Kletnieks
2003-02-14 0:18 Sam Vilain
2003-02-23 23:31 ` Zygo Blaxell
2003-02-24 1:14 ` Anders Widman
2003-02-14 0:17 Sam Vilain
2003-02-14 0:16 Sam Vilain
2003-02-23 23:10 ` Zygo Blaxell
2003-02-12 20:57 Dirk Schenkewitz
2003-02-12 18:27 Anders Widman
2003-02-11 19:43 berthiaume_wayne
2003-02-12 10:48 ` Dirk Schenkewitz
2003-02-12 10:59 ` Hans Reiser
2003-02-12 11:24 ` Frank Baumgart
2003-02-12 11:35 ` Stefan Traby
2003-02-12 11:54 ` Dirk Schenkewitz
2003-02-12 12:42 ` Hans Reiser
2003-02-12 13:25 ` Dirk Schenkewitz
2003-02-12 16:22 ` Sam Vilain
2003-02-12 16:53 ` Anders Widman
2003-02-12 17:19 ` Hans Reiser
2003-02-12 17:40 ` Anders Widman
2003-02-12 18:15 ` Dirk Mueller
2003-02-12 18:20 ` Anders Widman
2003-02-12 18:20 ` Chris Dukes
2003-02-13 20:08 ` Zygo Blaxell
2003-02-11 18:59 Dirk Schenkewitz
2003-02-11 20:27 ` Hans Reiser
2003-02-11 21:30 ` Mike Hodson
2003-02-11 21:47 ` Hans Reiser
2003-02-11 21:58 ` Hans Reiser
2003-02-12 6:35 ` Oleg Drokin
2003-02-11 23:11 ` Adam Goryachev
2003-02-11 23:17 ` Anders Widman
2003-02-12 0:12 ` Hans Reiser
2003-02-12 10:23 ` Anders Widman
2003-02-12 10:47 ` Hans Reiser
2003-02-12 11:12 ` Adam Goryachev
2003-02-12 13:42 ` Anders Widman
2003-02-12 14:15 ` Russell Coker
2003-02-12 15:26 ` Anders Widman
2003-02-12 16:22 ` bscott
2003-02-12 16:28 ` Russell Coker
2003-02-12 16:40 ` Anders Widman
2003-02-13 3:42 ` Zygo Blaxell
2003-02-13 10:13 ` Anders Widman
2003-02-13 14:44 ` Rudy Zijlstra
2003-02-13 3:31 ` Zygo Blaxell
2003-02-12 16:39 ` Sam Vilain
2003-02-12 5:12 ` Ross Vandegrift
2003-02-12 7:17 ` Oleg Drokin
2003-02-12 10:17 ` Alexander Lyamin
2003-02-12 10:19 ` Alexander Lyamin
2003-02-12 16:25 ` Vitaly Fertman
2003-02-12 16:56 ` Anders Widman
2003-02-12 17:13 ` Oleg Drokin
2003-02-12 1:02 ` Mike Hodson
2003-02-12 7:25 ` Oleg Drokin
2003-02-12 9:45 ` Hans Reiser
2003-02-12 16:09 ` Sam Vilain
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=3E5279C2.3090702@namesys.com \
--to=reiser@namesys.com \
--cc=adilger@clusterfs.com \
--cc=eazgwmir@umail.furryterror.org \
--cc=green@namesys.com \
--cc=reiserfs-list@namesys.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.