periodic "chkdsk /f" (How often is enough, or is *never* OK?)

  • Thread starter Thread starter Tom Rodman
  • Start date Start date
T

Tom Rodman

We had been scheduling a "chkdsk /f" on all our w2k server file systems
once per week when we reboot. We have ~100GB, so this can take several
hours. It's been hinted by others that w2k is smart enough to detect
a dirty filesystem before it get's too corrupted, so that we
should *not* have to schedule a "chkdsk /f" at all.

Comments?
 
Tom

Yes, I agree, you don't need to manually schedule a chkdsk. If a problem
with the file system is found, an event will be logged in the application
event log, and a chkdsk will automatically be scheduled for next restart.
This MS Knowledge Base article has more information:

http://support.microsoft.com/?id=218461

Best regards

Bjorn
 
Bjorn said:
Yes, I agree, you don't need to manually schedule a chkdsk. If a problem
with the file system is found, an event will be logged in the application
event log, and a chkdsk will automatically be scheduled for next restart.

Thanks Bjorn, I'm but I still need some convincing. I guess it
come down to how well the NTFS filesystem is designed and how much
you want to trust it.

Our experience with Windows NT indicated that "dirty flag" was
not always set properly by the OS. We would reboot, no chkdsk
was run automatically, then immediately reboot again with chkdsk
set to run, and find that chkdsk identified and repaired
problems in the filesystem.

Linux filesystems have the ability to either:

o run a filesystem check on each reboot
o run a filesystem check after N number of reboots
o run a filesystem check at reboot after X number days elapsed since last check

I take it uSoft says "not to worry",
maybe so, but does this agree with everyones' experience? I would
be most comfortable with at least a once/month forced check.
 
Tom Rodman said:
Thanks Bjorn, I'm but I still need some convincing. I guess it
come down to how well the NTFS filesystem is designed and how much
you want to trust it.

My experience - from reading and answering in MS newsgroups - is that NTFS
corruption is very sparingly seen in server halls. When I have seen
corruption myself, it was traced to malfunctioning hardware. In that case,
I trusted my backup.
Our experience with Windows NT indicated that "dirty flag" was
not always set properly by the OS. We would reboot, no chkdsk
was run automatically, then immediately reboot again with chkdsk
set to run, and find that chkdsk identified and repaired
problems in the filesystem.

Minor maintenance tasks are done when you run chkdsk. Cached unused
security descriptors are cleaned out. Those are not triggering the dirty
bit, thankfully.

This is what KB 255008 says about this process:

"All NTFS volumes contain a security descriptor database. This database is
populated with security identifiers that represent unique permission
settings that are applied to files and folders. When files or folders have
unique NTFS permissions applied, NTFS stores a unique security descriptor
once on the volume, and it also stores a pointer to the security descriptor
on any file or folder that references it.

If files or folders no longer use that unique security descriptor, NTFS
does not remove the unique security descriptor from the database, but
instead, keeps it cached. Like any caching strategy, you want to keep the
cached information as long as possible because it may be used again."
I take it uSoft says "not to worry",
maybe so, but does this agree with everyones' experience? I would
be most comfortable with at least a once/month forced check.

Of course, whatever makes you feel comfortable, but once a week seems
excessive to me.

Best regards

Bjorn
 
Tom Rodman said:
We had been scheduling a "chkdsk /f" on all our w2k server file systems
once per week when we reboot. We have ~100GB, so this can take several
hours. It's been hinted by others that w2k is smart enough to detect
a dirty filesystem before it get's too corrupted, so that we
should *not* have to schedule a "chkdsk /f" at all.

Bjorn would probably call this excessive paranoia, but I have a boot-time
check scheduled all the time. If I'm there when the system restarts, I
bypass it, by pressing a key when it prompts for one. If the system shutdown
abnormally in any way (BSOD, power loss, hang requiring power off), I let it
run.

I have a script (batch file) that runs on login that echoes the appropriate
y &| n chars
to chkdsk invocations against each drive.

The batch file consists of the following line:
((echo n & echo y) | chkdsk /f S:) & ((echo n & echo y) | chkdsk /f D:) &
echo y | chkdsk /f C:

Replace your own drive letters as necessary.

Phil
--
Philip D. Barila Windows DDK MVP
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
E-mail address is pointed at a domain squatter. Use reply-to instead.
 
Phil Barila said:
Bjorn would probably call this excessive paranoia

Not at all, seems like a good idea.
, but I have a boot-time
check scheduled all the time. If I'm there when the system restarts, I
bypass it, by pressing a key when it prompts for one. If the system shutdown
abnormally in any way (BSOD, power loss, hang requiring power off), I let it
run.

The only problem I see with this method is if you reboot servers from a
remote location, you wouldn't be able to say no to a chkdsk.

Also, with modern hardware and software, where BSOD's are seldom seen and
servers get power from an UPS, chkdsk wouldn't run very often, would it?

Best regards

Bjorn
 
Bjorn Landemoo said:
Not at all, seems like a good idea.


The only problem I see with this method is if you reboot servers from a
remote location, you wouldn't be able to say no to a chkdsk.

It's not harmful, and I don't run servers, so I'm not worried about it
taking a couple extra minutes. If I had multi-terabyte arrays, I'd be a lot
more concerned about it.
Also, with modern hardware and software, where BSOD's are seldom seen and
servers get power from an UPS, chkdsk wouldn't run very often, would it?

If I had servers, I'd use a UPS. Since I'm only describing what I do on
desktop systems, I just make sure stuff I really want to keep is stored
securely on UPS protected servers and arrays, and ameliorate the possible
consequences of power losses and other potential disasters.

Phil
--
Philip D. Barila Windows DDK MVP
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
E-mail address is pointed at a domain squatter. Use reply-to instead.
 
Back
Top