Fix the case where fsck would not see sparse directories and the kernel would

panic. If such a thing is fixed fsck needs a rerun (and bugs the user to do
so).

Reviewed by:	Kirk McKusick

2 files changed, 14 insertions, 1 deletions

diff --git a/sbin/fsck_ffs/SMM.doc/0.t b/sbin/fsck_ffs/SMM.doc/0.t
index 9de391e..528dd96 100644
--- a/sbin/fsck_ffs/SMM.doc/0.t
+++ b/sbin/fsck_ffs/SMM.doc/0.t
@@ -94,7 +94,7 @@ Both the program and the interaction between the
 program and the operator are described.
 .sp 2
 .LP
-Revised July 16, 1985
+Revised October 7, 1996
 .AE
 .LP
 .bp
diff --git a/sbin/fsck_ffs/SMM.doc/3.t b/sbin/fsck_ffs/SMM.doc/3.t
index 07b5431..bb6f05b 100644
--- a/sbin/fsck_ffs/SMM.doc/3.t
+++ b/sbin/fsck_ffs/SMM.doc/3.t
@@ -344,6 +344,19 @@ will remove that directory entry.
 Again,
 this condition can only arise when there has been a hardware failure.
 .PP
+.I Fsck
+also checks for directories with unallocated blocks (holes).
+Such directories should never be created.
+When found,
+.I fsck
+will prompt the user to adjust the length of the offending directory
+which is done by shortening the size of the directory to the end of the
+last allocated block preceeding the hole.
+Unfortunately, this means that another Phase 1 run has to be done. 
+.I Fsck
+will remind the user to rerun fsck after repairing a
+directory containing an unallocated block.
+.PP
 If a directory entry inode number references
 outside the inode list, then
 .I fsck