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

Mark Conrad wrote: 
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.

Your point?


Using those outside app's increases the chances for file corruption to
occur.
Only if your using apps that don't call upon OS X to write to the disk. Needless to say, these aren't very common.

The more app's I use, the greater the chances for corruption, 
This simply is not true.

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.
This is not at all the case. OS X (and by this, I include the vast majority of OS X apps) does active disk maintanence to circumvent the issues entirely. I just isn't succeptable to the same kind of disk problems OS 9 was.


(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, 
Your getting B-tree errors, this indicates that something is bad wrong.

merely adding updates to all the
various app's, repairing permissions because some of those updates mess
up the permissions.
Just to note, repairing permissions rarely does anything from a practical usage standpoint.

  I also take a quick look at the fragmentation of
my 20-GB partition, and if it is bad enough, I do a defrag'.
It shouldn't be getting fragmented in the first place. OS X has a wide array of technologies in place to almost completely elimiate the situations where fragmentation is an issue. Unless your continually rewriting large blocks of data at once, you shouldn't be having a problem here.


I admit a lot of my maintenance work is self inflicted, because of the
way I prefer to work here.
Very much self-inflicted--the majority of the steps you take are unnessesary, or are indicitive of a more serious problem.


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.
pdisk might cause partitioning issues, but nothing there would cause the type of problems you describe (I don't understand how dc might cause a problem of any sort, let alone the disk issues you describe).


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.
Why don't you just install the apps your going to use, then backup. Keep user data on a seperate partition or off on a server. When you need to restore just go back to the working system backup.


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.
Your doing a lot of extrenious crap that doesn't seem to be warranted from the usage you describe.


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.
Your doing a lot more work than any other OS X admin I know--and your usage pattern (from what you've described) doesn't seem to warrant the precautionary work you do.


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. 
The idea is that these fixes should be transparent.


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


are

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.
Your completely misevaluating the situation. IF anything, you should be doing LESS work with OS X than you did OS 9. It's a much, much easier system to maintain. You seem to be doing a hell of a lot of unnessesary work.


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.

No, no it's not. Mostly because of how well OS X handles disk management.


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: 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)
  • 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: Is FAT32 format gone?
    ... is nolimit> to partition size re FAT32-formatted partitions. ... FAT32 file system in a WinXPenvironment,> he or she can do ... Disk> Management utility, ...
    (microsoft.public.windowsxp.general)
  • Re: Chkdsk errors in SP2 installation
    ... Windows is on the first partition (that's the one I ... > the Error Checker in the disk Properties/Tools says the disk is OK. ... >>Windows found problems with the file system. ...
    (microsoft.public.windowsxp.general)
  • Re: EXL Cartridge Tape Reader in New England
    ... 440 words or data with an 8-word header containing 7 fields. ... In the Prime file system, records of a file are doubly linked, so the ... 65,536 disk records. ... bit integers and the maximum partition size increased to a theoretical ...
    (comp.sys.prime)