lkml.org 
[lkml]   [2004]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectKernel 2.6.6: Removing the last large file does not reset filesystem properties
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.087 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site