John Summerfied wrote: > What filesystem are you using? ext2/ext3 are supposed to handle this > pretty well and it's a very long time since I had a problem with them. > OTOH some others (and I don't want to cast nasturtiums) have less > stellar reputations. > > In any event, booting your rescue CD and running a filesystem check is a > good start. I'm a little torn about recommending a read-only check - it > sounds conservative, but it won't fix the problem. OTOH, a rw test > (necessary to fix it) also has the possibility to make it worse. I understand that there is no such thing as a read only check (or even a read-only mount) with ext3fs although if you know what you're doing, you *can* mount it as ext2fs "really-read-only". The point is that ext3 maintains a journal of actions which have to be applied to the filesystem before it is in a sane state, and it will make sure that the changes have in fact reached the filesystem before mounting it. Without writing these changes to the main filesystem, you're no better off than you were under ext2fs. So "read-only" on ext3fs just means "no *new* changes" to the filesystem structure. If you play with tune2fs the right way, you can convince ext2fs to think the filesystem was cleanly unmounted, and mount it read-only without reference to the journal. If you *really* know what you're doing, you *might* be able to salvage a little more data this way. See, for example, the first article at http://www.kerneltraffic.org/kernel-traffic/kt20010119_103.html My recommendation would be to backup any important data first, *then* fsck it and see what happens. James. -- E-mail address: james | Which do you consider was the stronger swimmer, @westexe.demon.co.uk | (a) The Spanish Armadillo, | (b) The Great Seal? | -- '1066 and All That'
