jay@metran.UUCP (Jay Ts) (06/02/91)
I have a few questions regarding fsck and crash recovery that I have not
been able to learn the answers to from TFM or my own experience:
1. When the system is booting after a crash, and fsck runs and reports
that it has cleared an inode, am I guaranteed that if it belonged to a
"real" file, that the file will be placed in the lost+found directory?
2. When I run
cd lost+found
file *
file may report that some of the entries are "directories". What does
this mean? If a file is "empty", does this mean that its contents were
lost, or that it was empty before the crash (or is it undeterminable?).
What I am really looking for is the answer to THIS:
3. Is it possible to *completely* recover a filesystem after a crash, when
fsck has modified the filesystem (other than when it simply sets its
state to "OK", that is)? If so, how?
... or should I just continue to reinstall the operating system from
scratch and backup tapes, as I have been doing?
What prompts this query is that I keep running into new clients' UNIX
systems that have been running for months or years with files in the
lost+found directories on one or more filesystem partitions, with apparently
no loss in functionality. Is it ok to just let them go like that?
Opinions accepted, but please document them as such!
Jay Ts, Director
Metran Technology
uunet!pdn!tscs!metran!jaycpcahil@virtech.uucp (Conor P. Cahill) (06/03/91)
jay@metran.UUCP (Jay Ts) writes: >1. When the system is booting after a crash, and fsck runs and reports >that it has cleared an inode, am I guaranteed that if it belonged to a >"real" file, that the file will be placed in the lost+found directory? If it clears an inode you get nothing in lost+found. Only unattached files/directories (ones that have no parent directory) get put into lost+found. >2. When I run > cd lost+found > file * >file may report that some of the entries are "directories". What does >this mean? This means that a directory was unattached. You should be able to cd to it and look around to see what is there. > If a file is "empty", does this mean that its contents were >lost, or that it was empty before the crash (or is it undeterminable?). Undetermined >3. Is it possible to *completely* recover a filesystem after a crash, when > fsck has modified the filesystem (other than when it simply sets its > state to "OK", that is)? If so, how? To be totally 100% safe you have to restore from backup. >What prompts this query is that I keep running into new clients' UNIX >systems that have been running for months or years with files in the >lost+found directories on one or more filesystem partitions, with apparently >no loss in functionality. Is it ok to just let them go like that? the reason for this is that the most likely files to be placed into lost+found are files that are modified by users. OS files/programs are much less likely to be modified and therefore not likely to be thrown into lost+found. I never restore from a backup just because I end up FSCKing a filesystem. >Opinions accepted, but please document them as such! All this stuff is opinions. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
bill@camco.Celestial.COM (Bill Campbell) (06/03/91)
This brings to mind a utility I've been meaning to write. It
would run daily and make an index by inode number of each
filesystem to make it easier to figure out what was what in a
lost+found directory after a crash.
Before I reinvent another wheel, has anyone already done this?
Bill
--
INTERNET: bill@Celestial.COM Bill Campbell; Celestial Software
UUCP: ...!thebes!camco!bill 6641 East Mercer Way
uunet!camco!bill Mercer Island, WA 98040; (206) 947-5591cmf851@anu.oz.au (Albert Langer) (06/04/91)
In article <1074@camco.Celestial.COM> bill@camco.Celestial.COM (Bill Campbell) writes: >This brings to mind a utility I've been meaning to write. It >would run daily and make an index by inode number of each >filesystem to make it easier to figure out what was what in a >lost+found directory after a crash. > >Before I reinvent another wheel, has anyone already done this? ISC 2.0.2 has ff(1) to list a file system in inode order. Don't know whether it is just ISC or not. BTW It had a bug which interpreted filenames with % in the name as though it was a printf formatting character. I don't know if this has been reported or fixed. (P.S. Anybody from ISC, please consider this a report :-) I have an awk script adapted from one by Tony Moraes, which converts an ls -alR listing into the same style as "find". It would be easy to use ls -ailR and include the inode number in the output and sort on that. The SunOs 4.1 find(1) has an -ls option which includes the inode number and you could sort on that. I have a vague idea there is a gnu or other public domain find floating around. If so, it may include this option. There is an option to the SunOs 4.1 find(1) that keeps some sort of database for faster searching instead of actually descending the directories each time. You might want to provide the functionality of that at the same time. Also there are various utilities e.g. from unix world and available on uunet, for keeping track of suid and sgid files and other permissions security issues and you might want to integrate some of the functionality of those. Other uses for such a database include backup and archive administration. It would be good to make it as general purpose as possible. -- Opinions disclaimed (Authoritative answer from opinion server) Header reply address wrong. Use cmf851@csc2.anu.edu.au
ed@mtxinu.COM (Ed Gould) (06/04/91)
>This brings to mind a utility I've been meaning to write. It >would run daily and make an index by inode number of each >filesystem to make it easier to figure out what was what in a >lost+found directory after a crash. >Before I reinvent another wheel, has anyone already done this? The ncheck program - if it exists in your version of UNIX - does exactly this. It was a standard part of the system through at least V7 and is still part of BSD. -- Ed Gould No longer formally affiliated with, ed@mtxinu.COM and certainly not speaking for, mt Xinu. "I'll fight them as a woman, not a lady. I'll fight them as an engineer."
bill@franklin.com (bill) (06/04/91)
In article <1991Jun4.020353.11910@newshost.anu.edu.au> cmf851@anu.oz.au (Albert Langer) writes:
: I have an awk script adapted from one by Tony Moraes, which
: converts an ls -alR listing into the same style as "find".
: It would be easy to use ls -ailR and include the inode number
: in the output and sort on that.
Urk. Why go to all the hassle?
find $dir -mount -print | xargs ls -di
gets you inode,file in a neat listing.cmf851@anu.oz.au (Albert Langer) (06/06/91)
In article <4Jun91.144729.1340@franklin.com> bill@franklin.com (bill) writes: >: I have an awk script adapted from one by Tony Moraes, which >: converts an ls -alR listing into the same style as "find". >: It would be easy to use ls -ailR and include the inode number >: in the output and sort on that. > >Urk. Why go to all the hassle? > > find $dir -mount -print | xargs ls -di > >gets you inode,file in a neat listing. True. The awk script was developed for processing the output of ftp ls commands where it is only possible to run ls but not find. (It also processes dates into a uniform sortable format instead of the different handling of recent and ancient dates by ls -l). While it would not be worth writing for the inode directory, I imagine it is probably more efficient than running ls on each small batch of file names with xarg. I also suggested the find -ls option which would be yet more efficient where available and ff which would be the most efficient. Don't forget he's planning to run this every day on every file. -- Opinions disclaimed (Authoritative answer from opinion server) Header reply address wrong. Use cmf851@csc2.anu.edu.au
bill@franklin.com (bill) (06/09/91)
In article <1991Jun6.070129.4796@newshost.anu.edu.au> cmf851@anu.oz.au (Albert Langer) writes: : In article <4Jun91.144729.1340@franklin.com> bill@franklin.com (bill) writes: : >: I have an awk script adapted from one by Tony Moraes, which : >: converts an ls -alR listing into the same style as "find". : >: It would be easy to use ls -ailR and include the inode number : >: in the output and sort on that. : > : >Urk. Why go to all the hassle? : > : > find $dir -mount -print | xargs ls -di : > : >gets you inode,file in a neat listing. : : True. The awk script was developed for processing the output of : ftp ls commands where it is only possible to run ls but not find. : (It also processes dates into a uniform sortable format instead : of the different handling of recent and ancient dates by ls -l). That solves a different problem and is probably overkill, though the date sorting is nice. I wish ls had an option to force a uniform output. Sigh. : While it would not be worth writing for the inode directory, I : imagine it is probably more efficient than running ls on each : small batch of file names with xarg. You end up reloading /bin/ls every N files, as compared to the inefficiency of using awk. (Which is *really* awful if you don't have a coprocessor.) If /bin/ls is chmod +t, this cost is very small. Also, you'd probably do a bit more I/O in the pipe with your method. Which is better can't be decided a priori; measurement seems in order but has to be done on the target system. : I also suggested the find -ls option which would be yet more : efficient where available and ff which would be the : most efficient. Yes. Where available. Find -ls isn't on SysV<4 systems (maybe on SysV4); ff is on mine, anyway, but I have no idea whether it is more efficient, nor if it is a standard. Also, ff uses the `ftw' package, I understand, and that will barf if your hierarchies go sufficiently deep. : Don't forget he's planning to run this every day on every file. Unless he's got a humongous partition, this is probably irrelevant. I already do several finds each day on my file systems, though for different reasons. (One, the "skulker" to trash old cores and a.outs, and another to collect statistics.) These run very quickly, even with my 272M of disk.