From owner-freebsd-fs Fri Jul 31 05:35:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA18484 for freebsd-fs-outgoing; Fri, 31 Jul 1998 05:35:24 -0700 (PDT) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from wkstn4-208.lxr.georgetown.edu (wkstn4-208.lxr.georgetown.edu [141.161.4.208]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA18479 for ; Fri, 31 Jul 1998 05:35:23 -0700 (PDT) (envelope-from mystify@wkstn4-208.lxr.georgetown.edu) Received: from wkstn4-208.lxr.georgetown.edu (localhost [127.0.0.1]) by wkstn4-208.lxr.georgetown.edu (8.8.8/8.8.8) with ESMTP id IAA01340 for ; Fri, 31 Jul 1998 08:35:19 -0400 (EDT) (envelope-from mystify@wkstn4-208.lxr.georgetown.edu) Message-Id: <199807311235.IAA01340@wkstn4-208.lxr.georgetown.edu> To: freebsd-fs@FreeBSD.ORG Subject: Trying to recover lost file Date: Fri, 31 Jul 1998 08:35:18 -0400 From: Patrick Hartling Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Last night, I did something phenomenally dumb and, to make a long story short, lost everything changed in my home directory between June 19 and last night. It was all in a tar file on a Jaz disk, and instead of restoring it, I removed it. :( I realize this is a very tall order, but is there anything I can do to get the file back? I realize that the general principle is that "once it's gone, it's gone," but I am very willing to spend hours, days, weeks, etc. trying to get this tar file back. It contains, among many other things, work I've done for my graduate research that I'd really rather not try to do over again if I can avoid it (even if it means spending more time trying to get it back than it took to do it in the first place). So, here's my situation. The file system on the Jaz disk has not been modified since I removed the tar file. I dd'd the entire file system to a file just to be safe. Running more(1) on that file shows that at least the file name of the deleted file is still in the file system in some form. A friend pointed me at fsdb(8), and I did an experiment with /usr/obj wherein I dd'd /dev/zero to a file for a couple of seconds, figured out which inode that file was at, removed it, then went to that inode to see what information was there. Everything looked the same, so now I am wondering what, if anything, can be done to "restore" that file? My file system skills and knowledge are poor at best, and some of what I've said here may sound ridiculous, but I am desperate enough to go through all 126,000+ inodes until I find something that looks vaguely like what I'm looking for (thank goodness for libedit(3)!). Thanks very much in advance. -Patrick Patrick L. Hartling | Research Assistant, ICEMT mystify@wkstn4-208.lxr.georgetown.edu | SE Lab - 1117 Black Engineering http://www.public.iastate.edu/~oz/ | http://www.icemt.iastate.edu/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jul 31 05:46:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA19411 for freebsd-fs-outgoing; Fri, 31 Jul 1998 05:46:25 -0700 (PDT) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from wkstn4-208.lxr.georgetown.edu (wkstn4-208.lxr.georgetown.edu [141.161.4.208]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA19406 for ; Fri, 31 Jul 1998 05:46:23 -0700 (PDT) (envelope-from mystify@wkstn4-208.lxr.georgetown.edu) Received: from wkstn4-208.lxr.georgetown.edu (localhost [127.0.0.1]) by wkstn4-208.lxr.georgetown.edu (8.8.8/8.8.8) with ESMTP id IAA01390 for ; Fri, 31 Jul 1998 08:46:20 -0400 (EDT) (envelope-from mystify@wkstn4-208.lxr.georgetown.edu) Message-Id: <199807311246.IAA01390@wkstn4-208.lxr.georgetown.edu> To: freebsd-fs@FreeBSD.ORG Subject: Argh .. followup to "Trying to recover lost file" Date: Fri, 31 Jul 1998 08:46:19 -0400 From: Patrick Hartling Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Okay, that experiment with /usr/obj was bogus I guess. I just went to the same inode again, and now it says it is unallocated. *sigh* I won't even attempt to guess why this is, but it's certainly not good news for me. So please disregard what I said conerning this attempt in my previous message. -Patrick Patrick L. Hartling | Research Assistant, ICEMT mystify@wkstn4-208.lxr.georgetown.edu | SE Lab - 1117 Black Engineering http://www.public.iastate.edu/~oz/ | http://www.icemt.iastate.edu/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jul 31 09:47:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA18032 for freebsd-fs-outgoing; Fri, 31 Jul 1998 09:47:48 -0700 (PDT) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from wanadoo.fr (smtp-out-2.wanadoo.fr [193.252.19.69]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA18024 for ; Fri, 31 Jul 1998 09:47:46 -0700 (PDT) (envelope-from jetienne@ifhamy.insa-lyon.fr) From: jetienne@ifhamy.insa-lyon.fr Received: from aralia.wanadoo.fr [193.252.19.42] by wanadoo.fr for Paris Fri, 31 Jul 1998 18:47:30 +0200 (MET DST) Received: from qmailr@meaux10-239.abo.wanadoo.fr [164.138.6.239] by smtp.wanadoo.fr for Paris Fri, 31 Jul 1998 18:47:27 +0200 (MET DST) Received: (qmail 216 invoked by uid 501); 31 Jul 1998 16:21:57 -0000 Message-ID: <19980731162157.215.qmail@hwi.poi.org> Subject: hmm lfs vs metadatalog To: freebsd-fs@FreeBSD.ORG Date: Fri, 31 Jul 1998 18:21:57 +0200 (MET DST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hi im new on this list and i have a question about lfs. why lfs is a "completly" log fs (i.e. data + metadata) and not a ffs + metadatalog. according to "the unix internals - the new frontiers" the second appreach is lighter and more efficient ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jul 31 14:16:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA01513 for freebsd-fs-outgoing; Fri, 31 Jul 1998 14:16:45 -0700 (PDT) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA01495 for ; Fri, 31 Jul 1998 14:16:42 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id OAA20398; Fri, 31 Jul 1998 14:16:37 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp02.primenet.com, id smtpd020326; Fri Jul 31 14:16:26 1998 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id OAA29689; Fri, 31 Jul 1998 14:16:23 -0700 (MST) From: Terry Lambert Message-Id: <199807312116.OAA29689@usr09.primenet.com> Subject: Re: Trying to recover lost file To: mystify@wkstn4-208.lxr.georgetown.edu (Patrick Hartling) Date: Fri, 31 Jul 1998 21:16:23 +0000 (GMT) Cc: freebsd-fs@FreeBSD.ORG In-Reply-To: <199807311235.IAA01340@wkstn4-208.lxr.georgetown.edu> from "Patrick Hartling" at Jul 31, 98 08:35:18 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Last night, I did something phenomenally dumb and, to make a long story > short, lost everything changed in my home directory between June 19 and > last night. It was all in a tar file on a Jaz disk, and instead of restoring > it, I removed it. :( I realize this is a very tall order, but is there > anything I can do to get the file back? I realize that the general principle > is that "once it's gone, it's gone," but I am very willing to spend hours, > days, weeks, etc. trying to get this tar file back. It contains, among many > other things, work I've done for my graduate research that I'd really rather > not try to do over again if I can avoid it (even if it means spending more > time trying to get it back than it took to do it in the first place). > > So, here's my situation. The file system on the Jaz disk has not been > modified since I removed the tar file. I dd'd the entire file system to a > file just to be safe. Running more(1) on that file shows that at least the > file name of the deleted file is still in the file system in some form. A > friend pointed me at fsdb(8), and I did an experiment with /usr/obj wherein I > dd'd /dev/zero to a file for a couple of seconds, figured out which inode that > file was at, removed it, then went to that inode to see what information was > there. Everything looked the same, so now I am wondering what, if anything, > can be done to "restore" that file? My file system skills and knowledge are > poor at best, and some of what I've said here may sound ridiculous, but I am > desperate enough to go through all 126,000+ inodes until I find something > that looks vaguely like what I'm looking for (thank goodness for libedit(3)!). Please tell me you were mounted sync, and tell me you didn't create any files on the drive after you did this! The first thing to do is to find the inode of the file that was deleted. To do this, you need to read-only mount a copy of the disk image, and go to the directory. If it was in /, you won't need the mount, since you will know that the root inode is inode #2. Go through the raw directory blocks. So long as you did not create any new files, the record will still be there. If the file was not the first file in a directory block, then the inode number of the file will still be there. If it was not the first, then you will need to go "fishing". If you need to go fishing, then you need to go through the directory blocks looking for a .tgz file signature: 00000000 1f 8b 08 00 61 67 d6 34 00 03 ed 5a 4b 53 e3 38 |....ag.4...ZKS.8| (this one is for a "gzip compressed data, deflated" file; see the file /usr/share/misc/magic for the range of posible numbers). Given the way tar and gzip operate on the input and output, this will probably be the first of a set of contiguous blocks of data. At a minimum, the size of an FS block. Knowing your block size at this point would be a good thing. Use the "tunefs" and "dumpfs" programs on the raw device: ex: # tunefs -p /dev/rsd0a tunefs: maximum contiguous block count: (-a) 7 tunefs: rotational delay between contiguous blocks: (-d) 0 ms tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time # dumpfs /dev/rsd0a magic 11954 time Fri Jul 31 20:35:34 1998 cylgrp dynamic inodes 4.4BSD nbfree 2220 ndir 63 nifree 6796 nffree 57 ncg 2 ncyl 32 size 32768 blocks 31759 bsize 8192 shift 13 mask 0xffffe000 fsize 1024 shift 10 mask 0xfffffc00 frag 8 shift 3 fsbtodb 1 cpg 16 bpg 2048 fpg 16384 ipg 3840 minfree 8% optim time maxcontig 7 maxbpg 2048 rotdelay 0ms rps 60 ntrak 1 nsect 2048 npsect 2048 spc 2048 symlinklen 60 trackskew 0 interleave 1 contigsumsize 7 nindir 2048 inopb 64 nspf 2 maxfilesize 549755813888 sblkno 16 cblkno 24 iblkno 32 dblkno 512 sbsize 2048 cgsize 4096 cgoffset 1024 cgmask 0xffffffff csaddr 512 cssize 1024 shift 9 mask 0xfffffe00 cgrotor 0 fmod 0 ronly 0 clean 0 (no rotational position table) cs[].cs_(nbfree,ndir,nifree,nffree): (1179,53,3572,6) (1041,10,3224,51) [ ... ] For my example, my block size is 8192 -- 8k. This means that after you find the signature, then you will have ~16 blocks of information, minimally, to start recovery. 8k is enough to partially decompress: # dd if=/dec/rsd0a skip={block offset} count=16 of=foo 16+0 records in 16+0 records out 8192 bytes transferred in 0.009735 secs (841501 bytes/sec) # cat foo | gunzip -f > foofoo # file foofoo gunzip: stdin: unexpected end of file # file foofoo foofoo: GNU tar archive # tar tvf foofoo [ ... verify this is your data ... ] Once you find the data, then you need to find the data blocks that reference it, and the inode that references them. Knowing the size that the file was so you know whether or not it used indirect blocks would be useful. Of course, if it wasn't the first entry in the directory, this is what happened when you deleted the file: Before: [ ][ ][ ] `----------> `------> `--------------------------> After: [ ][ ][ ] `--------------------> `--------------------------> ^ | In other words, the inode number is still there, and it's easier to work down than up... Unfortunately, all the tools I cobbled together to do this the last time I shot my foot off are on 6525 QIC tape, and they apply to the UFS in SunOS 4.1.3u1, and don't know anything about indirect blocks using negative offsets, etc.. One thing to note: free space is coelesced on creates. This means that if you created any files in the directory, you may have destroyed the directory entry identification of the inode number. If so, you get to grovel the disk (whee!). This is probably what fsdb sould be capable of, but it's not. In any case, once you get a set of block lists, you are home free. The use of compression makes things hardware on you; it is easy to identify the next block of data in a tar archive by using tar to test. It is harder to test using gzip for the next block of gzip data. You can either brute-force it, or you can hack up gzip. The moral of this story: keep important things unzipped if your backup storage is not a linear archival format (ie: an FS is not linear). If you must use compression, use a deterministic algorithm. Either specify it, or use UNIX compress, not gzip, so that if this happens, you don't have to grovel 20+ magic numbers. In any case, that should get you started. If you end up hacking tools out of this, the tools should be smart enough to avoid all allocated space. For a partially filled disk, this cuts down the work immensely. You may also want to make a offset-on-device-device; either that, or hack the magic program to be able to start it at non-zero offsets. Part of the problem with the magic (file) program is that its data format in the file is rather inflexible to arbitrary application of the information, and the license on the source code makes it a rewrite to add the capability in, if you want to distribute the resulting code. Let me know if you have any FS layout specific questions that you can't get answers on from the header files. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jul 31 16:51:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA26974 for freebsd-fs-outgoing; Fri, 31 Jul 1998 16:51:20 -0700 (PDT) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from post.mail.demon.net (post-11.mail.demon.net [194.217.242.40]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA26961 for ; Fri, 31 Jul 1998 16:51:17 -0700 (PDT) (envelope-from dmlb@ragnet.demon.co.uk) Received: from (ragnet.demon.co.uk) [158.152.46.40] by post.mail.demon.net with smtp (Exim 1.82 #2) id 0z2Owu-0007gk-00; Fri, 31 Jul 1998 23:51:00 +0000 Received: from dmlb by ragnet.demon.co.uk with local (Exim 1.82 #1) id 0z2Oth-0000fv-00; Sat, 1 Aug 1998 00:47:41 +0100 Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199807312116.OAA29689@usr09.primenet.com> Date: Sat, 01 Aug 1998 00:47:41 +0100 (BST) From: Duncan Barclay To: (Patrick Hartling) Subject: Re: Trying to recover lost file Cc: freebsd-fs@FreeBSD.ORG Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 31-Jul-98 Terry Lambert wrote: >> Last night, I did something phenomenally dumb and, to make a long story >> short, lost everything changed in my home directory between June 19 and >> last night. It was all in a tar file on a Jaz disk, and instead of >> restoring >> it, I removed it. :( I realize this is a very tall order, but is there >> anything I can do to get the file back? I realize that the general >> principle >> is that "once it's gone, it's gone," but I am very willing to spend hours, >> days, weeks, etc. trying to get this tar file back. It contains, among many >> other things, work I've done for my graduate research that I'd really rather >> not try to do over again if I can avoid it (even if it means spending more >> time trying to get it back than it took to do it in the first place). >> >> So, here's my situation. The file system on the Jaz disk has not been >> modified since I removed the tar file. I dd'd the entire file system to a >> file just to be safe. Running more(1) on that file shows that at least the >> file name of the deleted file is still in the file system in some form. A >> friend pointed me at fsdb(8), and I did an experiment with /usr/obj wherein >> I >> dd'd /dev/zero to a file for a couple of seconds, figured out which inode >> that >> file was at, removed it, then went to that inode to see what information was >> there. Everything looked the same, so now I am wondering what, if anything, >> can be done to "restore" that file? My file system skills and knowledge are >> poor at best, and some of what I've said here may sound ridiculous, but I am >> desperate enough to go through all 126,000+ inodes until I find something >> that looks vaguely like what I'm looking for (thank goodness for >> libedit(3)!). > > Please tell me you were mounted sync, and tell me you didn't create any > files on the drive after you did this! > > > The first thing to do is to find the inode of the file that was deleted. It won't help... Terry a big problem under FreeBSD is that it hoses the inode pretty quickly. I know, I did the same thing to a chapter of my PhD thesis a year or so ago. Found the inode as you described and it was all 0... > > Unfortunately, all the tools I cobbled together to do this the last > time I shot my foot off are on 6525 QIC tape, and they apply to the > UFS in SunOS 4.1.3u1, and don't know anything about indirect blocks > using negative offsets, etc.. Strange I've got a set too, but now they work on FreeBSD! >From what I remember SunOs doesn't zero the inode out. (I've mailed a copy to Patrick) Now I have RCS/CVS everywhere. Duncan --- ________________________________________________________________________ Duncan Barclay | God smiles upon the little children, dmlb@ragnet.demon.co.uk | the alcoholics, and the permanently stoned. ________________________________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jul 31 18:51:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA12164 for freebsd-fs-outgoing; Fri, 31 Jul 1998 18:51:12 -0700 (PDT) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from mongkok.hk.super.net (mongkok.hk.super.net [202.14.67.46]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA12159 for ; Fri, 31 Jul 1998 18:51:10 -0700 (PDT) (envelope-from raju@rssd.hk.olivetti.com) Received: from oli-super-gw.hk.olivetti.com (oligate.hk.olivetti.com [202.64.193.50]) by mongkok.hk.super.net (8.8.8/8.8.8) with ESMTP id JAA06838 for ; Sat, 1 Aug 1998 09:51:04 +0800 (HKT) Received: from olibbs.hk.olivetti.com (olibbs.hk.olivetti.com [202.64.192.2]) by oli-super-gw.hk.olivetti.com (8.9.0/8.9.0) with ESMTP id JAA24512 for ; Sat, 1 Aug 1998 09:51:03 +0800 (HKT) Received: from rssd.hk.olivetti.com (rssd.hk.olivetti.com [202.64.192.5]) by olibbs.hk.olivetti.com (8.8.7/8.8.7) with SMTP id JAA09245 for <@olibbs.hk.olivetti.com:freebsd-fs@FreeBSD.ORG>; Sat, 1 Aug 1998 09:51:02 +0800 (CST) (envelope-from raju@rssd.hk.olivetti.com) Message-Id: <199808010151.JAA09245@olibbs.hk.olivetti.com> Subject: Re: Trying to recover lost file To: tlambert@primenet.com (Terry Lambert) Date: Sat, 1 Aug 1998 09:48:32 +0800 (HKT) From: "Raju M. Daryanani" Cc: mystify@wkstn4-208.lxr.georgetown.edu, freebsd-fs@FreeBSD.ORG In-Reply-To: <199807312116.OAA29689@usr09.primenet.com> from "Terry Lambert" at Jul 31, 98 09:16:23 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Terry Lambert: > > The first thing to do is to find the inode of the file that was deleted. >From memory of Bach's "The Design of the UNIX OS", the inode should be the first on the free list, since he just deleted it. Or do things work differently on the Berkeley File System? Bach also mentioned that when you delete a file its data blocks are placed on the block free list in reverse order. Again I don't know if this applies to the Berkely File System, but if it's the case it could simplify the undeletion. Raju -- Raju M. Daryanani | Email: raju@rssd.hk.olivetti.com Network Integration Acting Manager | raju@hk.super.net Greater China | Tel: +852 2979 2450 / Fax: +852 2802 6591 Olivetti (HK) Ltd. | [MIME understood] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jul 31 19:43:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA17287 for freebsd-fs-outgoing; Fri, 31 Jul 1998 19:43:59 -0700 (PDT) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA17278 for ; Fri, 31 Jul 1998 19:43:54 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id TAA09402; Fri, 31 Jul 1998 19:43:50 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd009376; Fri Jul 31 19:43:45 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA04462; Fri, 31 Jul 1998 19:43:41 -0700 (MST) From: Terry Lambert Message-Id: <199808010243.TAA04462@usr06.primenet.com> Subject: Re: Trying to recover lost file To: raju@rssd.hk.olivetti.com (Raju M. Daryanani) Date: Sat, 1 Aug 1998 02:43:41 +0000 (GMT) Cc: tlambert@primenet.com, mystify@wkstn4-208.lxr.georgetown.edu, freebsd-fs@FreeBSD.ORG In-Reply-To: <199808010148.JAA09234@olibbs.hk.olivetti.com> from "Raju M. Daryanani" at Aug 1, 98 09:48:32 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > The first thing to do is to find the inode of the file that was deleted. > > > >From memory of Bach's "The Design of the UNIX OS", the inode should be the > > first on the free list, since he just deleted it. Or do things work > differently on the Berkeley File System? Bach also mentioned that when > you delete a file its data blocks are placed on the block free list in > reverse order. Again I don't know if this applies to the Berkely File > System, but if it's the case it could simplify the undeletion. The free list in question is in RAM. The inodes on disk are pretty much allocated at random in random cylinder groups to effect a perfect hash. The blocks are allocted in clusters, where possible. There used to be a "free list" in the FFS (which was the basis for the SVR4 UFS). The old System V FS that predates UFS (FFS) used to keep bad blocks off of inode 1. This is why the root inode is inode 2, and why most archiving tools state, see inode 1, and bail to the next inode entry. Inode allocation is noted in the inode bitmap, and block allocations are noted in teh cylinder group bitmap. I wasn't sure about the lateness of the inode content clearing and binding (it's been a while since I saw that exact code), but it makes sense that the inode block offsets would be cleared, since in order to do deterministic recovery, you need to do the writes in the inverse of allocation order. If it is zeroing inodes before writing them, then IMO it would be worthwhile to steal a flag bit for "invalid" instead, as long as there is not a non-atomic operation that appears idempotent that depends on the behaviour. The same can be said of the use of a zero'ed inode field for "deleted" in the first directory entry, since flag bits could be provided. In fact, I would be tempted to mark files "deleted" for later purge, and use fcntl's on the directory fd to decide whether they get returned or not in a VOP_READDIR(). Remniscent of NetWare, allowing "undelete" until a manual or space-crunch auto-purge. LRU'ed, of course. 8-). In any case, it's possible to write a recovery tool that pretty much automates recovery based on cylinder groups. Getting the frags is a bit harder, but can be done. If the tools are generally good, they should be made generally available, I think. When I was recovering my stuff on SunOS, I was bit-banging hard enough, even after double-buffering (or maybe because of it) that sustained block searches cause the disks to offline due to heating. 8-). This is not something you want to do a lot of... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message