On Fri, 22 Sep 2000 [EMAIL PROTECTED] wrote:

>> deeper fs knowledge however.  If one finds themselves frequently
>> experiencing corruption problems, it might pay to learn the
>> filesystem internals.  A good day or two's reading I believe
>> should give plenty of info to handle most situations.  There are
>> several howto's, and on the web there are ext2 documents by Ted
>> T'so I believe, and perhaps others..  I've got a few kicking
>> around.  ext2 isn't that hard to understand, although I'm a bit
>> rusty on it right now since I haven't had to use debugfs in over
>> 3 years.  ;o)
>> 
>
>Problem about reading for a couple days is that this implies user's
>job is knowing everything about system administration.

I think we're speaking in different terms here..  ;o)  If someone
_is_ a system admin, in any way, then if they don't know how to
sys admin, then they shouldn't be.

If it is an end user system, then obviously they shouldn't have
to be joe sys-admin, so I agree with you in that respect.

>This is possible if eiuser is a consultant or user is a system
>administrator in a big compnay so there are hundred people
>around user going with the task of making money for the
>company.  If company is three of four persons or if user is a
>private individual this kind of "learning overhead" is
>unacceptable (no time left for real work).

If someone is running Linux on a business system, and has
problems that they can't deal with, they should hire someone who
_can_ deal with the problem to do so.  This is business, and lost
time means money.  If that is unaffordable, then they should
consider the alternative operating systems and their associated
costs.

As it stands now, for joe user or joe sysadmin, fsck is a
possible fact of life.  Either one minimizes the chances of
problems in the first place, by using a UPS, or some other
method, or they use a different filesystem.  fsck is unlikely to
get any easier anytime soon.  Perhaps it will get a GUI frontend
or something but I wouldn't count on it anytime soon.  If you
look at a Windows system, SCANDISK presenting the user with a
"4234 lost clusters found in 34 chains, fix?" is no different
from what fsck is doing.  The alternative in either case is to
either auto-yes, auto-no, or leave the filesystem corrupt.  It is
really not something you encounter every day on a home system for
joe user however, so I don't see it to be a big issue.  If
someone _is_ getting it a lot, then they should use the mailing
lists, for support to find out why and possibly try a journalled
filesystem.

My main point is that as long as one uses ext2fs, and has unclean
mounts, fsck is going to run, and you either learn it - which may
be impossible for some, or completely undesireable, or you
reformat or reinstall (windows methodology).  The latter is sad,
but what other option is there.  Operating system recovery in
_any_ OS is not for the beginner, and will lead often to complete
reinstalls.  Linux is no different.  Even a journalled fs can
become corrupt too, if a bad driver or something in-kernel
garbles the disk, such as bad parameters passed to hdparm.  So
the problem isn't entirely just a filesystem feature one, but
rather a general computer one.  There is no easy answer other
than "learn what you can about whatever OS's you use so you can
fix them yourself when they break", or "pay someone to fix it for
you", or "reinstall often".

Sadly, those are the choices.  If someone is patient enough
though with problems they have, they can get pretty good help on
these mailing lists.  I would rather help someone with fsck, and
related utils than see them lose data and reinstall.

Well, gotta get some food into me...  take care,
TTYL

--
         Mike A. Harris  -  Linux advocate  -  Open source advocate
                   Copyright 2000 all rights reserved
                               ----------
Be up to date on nerd news and stuff that matters:  http://slashdot.org



_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list

Reply via email to