From: Manuel Krause <manuelkrause@netscape.net>
To: reiserfs-list <reiserfs-list@namesys.com>
Subject: Re: A couple of questions
Date: Fri, 17 May 2002 02:17:13 +0200 [thread overview]
Message-ID: <3CE44C09.4040607@netscape.net> (raw)
In-Reply-To: 20020516214419.GE15774@schmorp.de
Hi '""pcg\"@goof.com ( Marc) (A.) (Lehmann )' and all others!
On 05/16/2002 11:44 PM, pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:
> On Thu, May 16, 2002 at 05:23:42PM -0400, Kuba Ober <kuba@mareimbrium.org> wrote:
>
>>What I'm thinking of is this:
>>to the user, which most users w/o intimate filesystem knowledge won't be able
>>to answer at all?
>>
>
> Unix traditionally wasn't aimed at the point-and-click users without
> knowledge.
Don't loose contact with reality. Nowadays things change very often. And
at least Linux has to be usable for a "traditional Win user" soon if
it should exist in future.
>
>>Looking at this list, what people want is to get their data
>>back, as much as possible. They never want to get less than that. Why bother
>>asking?
>>
>
> Users who know nothing can still be told to just press "y". Even better,
> somebody with some knowledge about the filesystem (and the contents!)
> layout can often do better with an interactive fsck (see ext2fs).
>
> I don't think it makes sense to enhance the dumb-user-mode while at the same
> time keeping informed users from working properly.
>
It makes sense to improve all user modes (in docs and usability) AND all
automatic modes possible depending on the distro. Pardon, what is an
"informed" user? Someone who reads the Docs or someone who can decidedly
type "Yes"... and make a repeat loop??
>
>>that is what many unsuspecting users actually do. It should simply disregard
>>read errors and try using whatever data there is in ok-read blocks.
>>
>
> It should actually ask the user wether she wants the block to be repaired
> (if possible), or permanently marked defect.
Doesn't that really depend on the HW state <-> or can software reliably
decide whether the info it gets is o.k. so far on Linux?? See the
previous posts on the list.
>
>>I don't think that asking too many questions is worth it. He who runs fsck in
>>"fix" mode wants his data back (whatever is left of it).
>>
>
> Thats a big mistake. He who runs fsck wants to recover as much data as
> possible. Sometimes maybe more than fsck alone can do.
>
We all running "reiserfsck" want as much data back as possible and are
in fear the FS has lost some things or is loosing things while running
fsck (what is real with ext2 and vfat). What is a big mistake on
reiserfs at least as it retrieves "mostly all" things possible. O.k.
that point is inaccurate.
>
>>recovery stuff should be w/o questions in my opinion. At least that's what
>>I'd expect all fsck's to do.
>>
>
> for some strange reason no fsck behaves like that.
>
Yess. I agree on that opinion. The fixable things should pass without
any question. Who knows the special missing inode, when it should be fixed?
Best wishes,
Manuel
next prev parent reply other threads:[~2002-05-17 0:17 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-16 18:44 A couple of questions Steve Pratt
2002-05-16 18:55 ` Oleg Drokin
2002-05-16 20:33 ` Hans Reiser
2002-05-16 21:23 ` Kuba Ober
2002-05-16 21:44 ` Lehmann
2002-05-16 21:44 ` Lehmann
2002-05-16 23:57 ` Hans Reiser
2002-05-17 0:45 ` Philipp Gühring
2002-05-17 1:06 ` Manuel Krause
2002-05-17 15:21 ` Kuba Ober
2002-05-17 0:17 ` Manuel Krause [this message]
2002-05-17 15:04 ` Kuba Ober
2002-05-18 20:40 ` Hans Reiser
2002-05-17 15:05 ` Kuba Ober
2002-05-17 13:10 ` Valdis.Kletnieks
2002-05-17 15:35 ` Kuba Ober
-- strict thread matches above, loose matches on Subject: below --
2010-05-27 13:39 Paul Millar
2010-05-27 14:56 ` Hubert Kario
2010-05-31 17:59 ` Paul Millar
2010-06-02 16:19 ` Hubert Kario
2010-05-27 16:00 ` Chris Mason
2010-05-31 18:06 ` Paul Millar
2010-05-31 20:33 ` Mike Fedyk
2010-06-02 11:56 ` Paul Millar
2010-06-01 13:39 ` Martin K. Petersen
2010-06-02 13:40 ` Paul Millar
2010-06-04 1:17 ` Martin K. Petersen
2005-04-18 11:51 Imre Simon
2005-04-18 15:31 ` Linus Torvalds
2005-04-18 16:23 ` Paul Jackson
2002-05-17 15:27 Steve Pratt
2002-05-17 13:11 berthiaume_wayne
2002-05-17 16:03 ` Kuba Ober
2002-05-16 18:48 Steve Pratt
2002-05-16 15:11 Steve Pratt
2002-05-16 15:35 ` Oleg Drokin
2002-05-16 14:52 Steve Pratt
2002-05-16 15:13 ` Hans Reiser
2002-05-15 21:22 Steve Pratt
2002-05-16 5:20 ` Oleg Drokin
2002-05-16 9:42 ` Hans Reiser
2002-05-16 11:40 ` Oleg Drokin
2002-05-16 11:54 ` Hans Reiser
2001-10-10 11:28 Adil EL YOUSSEFI
2001-10-10 12:11 ` David Woodhouse
1999-03-02 13:11 Neil Booth
1999-03-15 18:58 ` Stephen C. Tweedie
1999-03-15 22:46 ` neil
1999-03-16 12:22 ` Stephen C. Tweedie
1999-03-16 2:11 ` Andrea Arcangeli
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=3CE44C09.4040607@netscape.net \
--to=manuelkrause@netscape.net \
--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.