Well Yes, '-f' switch, This does mean --force the check ?
I'll admit ass-u-me(tion), but the man page does say:
" -f Force checking even if the file system seems clean."
If all it's going to do is re-read the cache then the -f
switch seems to be a useless option .
I've been of the opinion that when -f is used it -reads- the disk
not a possibly corrupt / might not reflect the disk, cache file.
Yes I know that everyone who's worked on the caching schemes
have done their honest best .
When I ask a utility that's going to tell me my filesystem
is clean, I'd really like it to check the FS not the cache.
my $.02-1/2 ;-)
The -f switch means precisely what the man page says --- force the
filesystem to be checked even if the dirty bit in superblock is clear.
E2fsck is concerned about checking filesystem for consistency, and it
*is* checking the filesystem.
You are assuming that the only valid place for the filesystem is on the
disk. What about the track buffers within the disk drive itself ---
it's caching data? Some disk controllers cache disk blocks as well.
Your argument that you're only checking the filesystem when you've
bypassed all of the caches is, well, silly. In practice, it's
impossible. What about the memory caches on the motherboard? Or within
the CPU chip itself? If you don't trust your caches, don't use a modern
system. Heck, even DOS uses cacheing techniques.
There is a -F option to e2fsck which will flush the buffer cache before
you start. On the other hand, the second time e2fsck reads a block, it
will be reading it from the buffer cache, not from disk again. If you
want the e2fsck disk to be slower just so that you can feel good because
the little red LED on your disk drive is turned on --- feel free to use
the -F option. The -F option is there only for consistent benchmarking,
though --- I didn't intend it to be for people who don't trust the
buffer cache, because as I said earlier --- that's impossible.
If you don't trust the buffer cache, don't use Linux.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu