Don't Fix It if it is Not Broken (was Looking at Macs...)




TheLetterK pontificated -
> > plus the desirability to keep a lot of the app's in the same
> > partition as the OS, makes for a horrendously bigger partition that
> > needs more time consuming maintenance.
>
> OS X performs a LOT more in the way of automated disk maintanence than
> OS 9 did. Very rarely should you actually need to manually perform disk
> maintanence.

Agreed, OS X does a lot more in the way of self maintenance.

However...

OS X itself is only a few GBs. If OS X were the only thing in my
partition, I would agree with you, that it would rarely need any
maintenance other that the self maintenanance it automatically does.

The problem arises when outside app's are added. I added two things,
iLife and iWork, plus a few util's like TechTool, so already I am up to
8.5 GBs being used in my 20 GB partition.

Using those outside app's increases the chances for file corruption to
occur. The more app's I use, the greater the chances for corruption,
therefore it makes sense to maintain the OS and the file system more
often, because they are both being used more heavily, so therefore more
subject to being corrupted.

(whew, that was a long mouthful)




> > Many things can go wrong on those big partitions. I seem to be
> > spending a lot of my time doing routine maintenance lately.
>
> Then you have something very wrong going on. What, exactly, are you
> doing and what's causing this to occur?

Naw, nothing "really wrong" going on, merely adding updates to all the
various app's, repairing permissions because some of those updates mess
up the permissions. I also take a quick look at the fragmentation of
my 20-GB partition, and if it is bad enough, I do a defrag'.

I admit a lot of my maintenance work is self inflicted, because of the
way I prefer to work here.

Explanation -
***********************************
In an effort to learn a little Unix, I find it necessary to
"experiment" with using the built in Unix app's that come with OSX,
like the commands dd, dc, pdisk, rm, split, chmod, plus all the many
"arguments" used to modify how those Unix commands work.
Those commands are very dangerous, so often I completely zap my
OSX, and the HFS+ file system, and even the partition structures.
Stuff gets damaged to the extent where conventional backup utilities
will not restore my disk, so I have to use a custom backup scheme.

Okay, so when I add any significant software to my OS X partition,
software that needs a lot of tedious configuration and setup in order
to work properly, I have to create a new custom backup file.

This is a real hassle, involving many hours of "maintaining" OSX, doing
stuff like freshly restoring the OSX partition from the "present"
backup file, repairing permissions, rebuilding the directory, repairing
the file system, defragging the OSX partition, wiping the free space of
the OSX partition, creating the new backup itself, then compressing a
copy of the new backup file to be stored on a off-site disk.

Then I can settle down to work for a day, week, or month until another
significant application demands that I create a newer backup file.

With my newest backup file at-the-ready, I can learn new Unix tricks to
my heart's content, secure in the knowledge that I can restore my disk
if I mess anything up.
************************************
End of Explanation



> > (no "journaling" on, by the way, on my 20 GB internal drive)
>
> Why don't you enable journaling? There's no reason to keep it off
> unless your actively doing disk maintanence.

Agreed, I failed to make that clear, it was a temporary turn-off of
journaling. Journaling is valuable because it essentially repairs
file system damage shortly after it happens, keeping a bad file system
from continually damaging files over a long period of time.

Perhaps a few files incur damage, but not a whole bunch of files.

My main objection to how journaling works in OS X is that it does not
_report_ when it "fixes" the file system.

If it reported, then at least I would be aware that a file may have
been damaged.



> > SURPRISE, massive failure, disk repair gave up, showed a message:
> > "B-tree node invalid value, can't repair"
>
> You might want to check the drive integrity if B-tree errors keep
> popping up. That is *not* a normal occurance.

I never did find out what caused it. After much diddling, the error
disappeared, never to come back again.

Unfortunately, this was all in the wee hours of the morning and I was
tired, so I made the cardinal mistake of not recording what I did
during my "diddling", so I have no idea why the error cleared up.




> > I have ran for literally many months on my external OS X drive, without
> > doing any regular maintenance on it. I am a bit more cautious with
> > my main internal drive, adding updates, pestering the drive partitions
> > with rebuilding their directories, low-level disk checking, rebuilding
> > "Volume Structures" and files with TechTool, even an occassional disk
> > defragging episode.
>
> You are aware that you can do more damage with over-caution than with
> under-caution, yes? It's a case of 'don't fix it if it's not broken'.

Ahh, now at long last we get down to the real meat of the subject line
of this post ;-)

> It's a case of 'don't fix it if it's not broken'.


Well, yes and no, an alternate saying could be:

"Fix it to keep it from breaking" <g>


I know what you are getting at, though. Excessive testing on its own
can easily cause damage.

It is hard to determine what is too little testing, versus what is too
much testing.

My rule of thumb is that the more likely something is to fail, the more
often I am going to test it.

I seldom test newer disk drives, but I often test older ones.

Same with newer RAM versus old RAM.

RAM has a definite life span, according to IBM (see item "4." in
website below -

<http://www.anandtech.com/guides/viewfaq.aspx?i=3>



A file system handling a tremendous amount of file traffic in a very
crowded and huge OS X partition is more likely to fail than a lightly
used file system, so therefore will need more maintenance attention
from utilities like TechTool Pro.

An old Mac subjected to heat, cold, vibration, humidity, dust, oil
fumes, and heavy usage is going to get all sorts of testing from me.

My new 17" powerbook is setting a few feet away from me in its hard
case, with fresh silica gel inside. Ya know, I have not ran one test
on that in several weeks.<g>

Gotta take it out of its case one of these days, to charge its battery.

Mark-
.



Relevant Pages

  • Re: Looking at Macs from a PC users perspective
    ... just running a seperate Unix/Linux partition on a PC? ... Very rarely should you actually need to manually perform disk ... spending a lot of my time doing routine maintenance lately. ... rebuild the directory by using TechTool's directory rebuild utility. ...
    (comp.sys.mac.advocacy)
  • Re: Linux community software-update-anarchy polemic
    ... Remember, I'm just a monkey. ... That implies that if you have one disk per partition, ... Trust the kernel or don't trust the kernel, but either way, both ...
    (comp.os.linux.misc)
  • SUMMARY: Moving /usr From Under Root "/" To Its Own Partition
    ... One of the reasons for doing this is to end up with a smaller root ... Install the boot block and boot off the new drive. ... " In order for the root partition to be fscked and remounted ... D> temporarily on the existing disk. ...
    (SunManagers)
  • Re: Two "expert" issues I must solve before upgading
    ... I think backups are different than the other fluff you suggest - more ... out there who had a disk crash and had to start from scratch. ... >image of your current Windows 98 OS partition. ... you can restore the disk image and get back quickly ...
    (microsoft.public.windowsxp.newusers)
  • Re: Found the chkdsk log [STOP error, data unviewable etc...]
    ... The type of the file system is NTFS. ... CHKDSK is recovering lost files. ... 33013543 KB total disk space. ... partition, etc. Oh well... ...
    (microsoft.public.win2000.file_system)