Kernel 2.6.6: Removing the last large file does not reset filesystem properties

[John McGowan]

Bug: Removing the last large file does not reset filesystem properties

SYSTEM: Pentium III, Fedora Core1 (gcc 3.3.2), Kernel 2.6.6

Symptom: [you can skip this]
----------------------------
 1: For the first week, at least, after installing a new kernel, I set the
    system to force fsck on boot (Fedora Core1, rc.local script to "touch"
    "/forcefsck").

 2: Home system, single user. Turn off at night. Turn off when I go to eat
    lunch. Etc. (reboot at least once each day - silly, but it is a single
    user system and I don't want to waste electricity and it gives better
    protection against storms and line spikes).
    
 3: Was using Gimp 2.0 and used a tool. Got a 6 Gig swap file in /tmp/gimp2
    (there must be a problem with that tool). Closed gimp, got rid of the
    swap file. Upon the next boot I got:
      FAILED!!
      Dropping to root command line for system maintenance
    (such fun ... entering the root password got more error messages about
    missing programmes such as "id" and "test" - well, I have "/usr" on
    another partition and it was not mounted).
  
  4: Typed reboot, everything was fine.
---------------------


CREATING/DUPLICATING THE PROBLEM:
---------------------------------
 So ... I created a 3Gig file, deleted it and booted to my "recovery"
 partition (I haven't removed RH72 yet, so I can boot to that to work
 on the Fedora system partitions without running e2fsck on a mounted,
 active, partition).
 
 I ran:
 
  PREFORCE:  dumpe2fs       on the Fedora Core1 partition
             e2fs -n -f -v  on the Fedora Core1 partition
  
  NOFORCE:   e2fs -v        on the Fedora Core1 partition
  
  FORCE:     e2fs -f -v     on the Fedora Core1 partition
  
  POSTFORCE: dumpe2fs       on the Fedora Core1 partition
             e2fs -n -f -v  on the Fedora Core1 partition

I was happy to see that there is no difference between the "e2fs -n -f -v"
run before and after the force of FSCK.

Running "e2fs -v" (no force, but not a read-only mount) did nothing 
("/1: clean, 35963/1154176 files, 197142/2303910 blocks"
 - by the way, since I still have RH72 on the system, the label of its
 root partition being "/", the root partition for Fedora is "/1")
since it was unmounted cleanly.

I was happy to see only one difference between the "dumpe2fs"
run before and after the force of FSCK (besides the time and mount count)


  AFTER DELETING THE LARGE FILE AND BEFORE FORCING FSCK:
    (dumpe2fs)
    Filesystem features:      has_journal filetype sparse_super large_file
    (e2fs -n -f -v)
    0 large files
  
  AFTER DELETING THE LARGE FILE AND FORCING FSCK:
    (dumpe2fs)
    Filesystem features:      has_journal filetype sparse_super
    (e2fs -n -f -v)
    0 large files

It looks like the only problem is that removing the last large file left the
filesystem thinking it had a large file. The error message given by Fedora
Core1 (if someone forces fsck and seldom has large files, for example, only
created by working on multimedia and they are later deleted) can be somewhat
unnerving.    
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/