dangers of delaying an fsck on busy fileserver ?

[Scott Long]

Gore Jarold wrote:
> I have a busy fileserver - 5-20 sftp/rsync processes
> running on it at all times.
> 
> For unknown reasons, this server crashes in the middle
> of the night sometimes.  When it does, I comment out
> my four big arrays in /etc/fstab, reboot, and fsck
> them manually (without a snapshot and BG fsck).
> 
> Easy.  The problem is, I need to sit around and wait
> for an fsck in the middle of the night and then
> re-edit fstab and reboot.
> 
> So I am curious ... what happens if I instruct the NOC
> tech to just press the reset switch instead of calling
> me ?  If he does this, the system will boot, the
> arrays will come online, and since I have a very very
> long time set until bg_fsck starts, I can then reboot
> the machine and foreground fsck it during sunlight
> hours.
> 
> But it does mean that users will continue to operate
> on those dirty disks for 4-8 hours until I do that.
> 
> Is this a dangerous strategy ?
> 
> Does this put me at some increased risk of finding
> myself with disks that cannot be fsck'd ?  (I've never
> seen it, but I have heard horror stories...)
> 
> Will I lose a lot of the data that has been transacted
> during the hours that the disks were used in a dirty
> state ?
> 
> Any comments ?
> 

In an ideal world, the only consequence of delaying bgfsck is that
not all filesystem blocks will be marked free that should be.  So
if you deleted a large tree of files before the crash, those blocks
might still show up in use until bgfsck completes.

Scott