>> I found your oneliner very useful, but still have to say that the
>> most tedious part is not modifying files, but writing down all
>> reported inode numbers (from fsck pass). If you have lots of disk
>> space, fsck can take some time, and you're spending that time
>> watching the screen, writing inode numers in a hurry, so you can
>> check later if any major corruption happened.
> I agree that it would be very nice for fsck to have some kind of
> logging mechanism.
> Perhaps, if it's being run non-interactively, you could tee the
> output to a file? Maybe have a scratch partition (where nothing of
> long-term importance is kept) which is mounted read/write before
> doing fsck on any of the rest of your partitions?
How about something like the following:
Q> mke2fs /dev/hdc2
Q> mount -t ext2 /dev/hdc2 /tmp
Q> fsck -V -a | tee /tmp/fsck.log.`date +%Y-%m-%d.%T`
It would require the following line in /etc/fstab to work:
Q> /dev/hdc2 /tmp ext2 defaults 0 0
Note the last two values: since this partition is recreated every
boot, it never needs checking anyway...
> That said, getting a UPS to allow for clean shutdowns is probably a
> better way to spend your time. [That said, a UPS won't prevent the
> kernel from having problems.]
True...
Best wishes from Riley.
--- * ftp://ps.cus.umist.ac.uk/pub/rhw/Linux * http://ps.cus.umist.ac.uk/~rhw/kernel.versions.html
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/