From owner-freebsd-questions Tue Jun 25 14:15:27 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21308 for questions-outgoing; Tue, 25 Jun 1996 14:15:27 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA21290 for ; Tue, 25 Jun 1996 14:15:16 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA00722; Tue, 25 Jun 1996 14:14:34 -0700 From: Terry Lambert Message-Id: <199606252114.OAA00722@phaeton.artisoft.com> Subject: Re: int link(const int inode, const char *name2) To: bill@twwells.com (T. William Wells) Date: Tue, 25 Jun 1996 14:14:34 -0700 (MST) Cc: freebsd-questions@FreeBSD.ORG In-Reply-To: <4qpggg$g1r@twwells.com> from "T. William Wells" at Jun 25, 96 04:00:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > : There is also the danger that the recovery process could not be > : initiated successfully if the system starupt created files and > : (potentially) reused blocks from the file (probability depends on > : file size relative to disk size times number of blocks allocated > : for temp files of one kind or another on startup on that disk. > > Now I'm completely convinced you don't know what you're talking > about. One of two conditions obtains at boot: either the inode > remains on disk and so it holds the data blocks or the inode does > not. If the former, the system startup can create files till the > fs is full and the file's data won't be touched. If the latter, > the file is already gone, gone, gone and it'll be nearly > impossible to recover the data, no matter what the startup does. Tell me: if an inode with a zero reference count is on disk and yet marked allocated (only possible if the machine was to be powered off with an unlinked yet open file), then is the precedence order such that the link count will be recovered because the blocks are validly referenced by the inode, and the file placed in lost+found, OR will the inode be cleared on the assumption that the system went down after the file was deleted but before the inode was marked free (which is, if you think about it, exactly what is happening)? You are confusing inode and vnode reference counts, I think. The inode reference has already gone to zero when the file was deleted, but it was not reclaimed because of the open reference at the time the 1->0 link count (reference count) occurred. >From the fsck man page: Inconsistencies checked are as follows: 1. Blocks claimed by more than one inode or the free map. 2. Blocks claimed by an inode outside the range of the filesystem. (1) 3. Incorrect link counts. 4. Size checks: Directory size not a multiple of DIRBLKSIZ. Partially truncated file. 5. Bad inode format. (2) 6. Blocks not accounted for anywhere. 7. Directory checks: File pointing to unallocated inode. Inode number out of range. Dot or dot-dot not the first two entries of a directory or having the wrong inode number. 8. Super Block checks: More blocks for inodes than there are in the filesystem. Bad free block map format. Total free block and/or free inode count incorrect. (3) Orphaned files and directories (allocated but unreferenced) are, with the operator's concurrence, reconnected by placing them in the lost+found di- rectory. The name assigned is the inode number. If the lost+found di- rectory does not exist, it is created. If there is insufficient space its size is increased. The question, then, is whether or not the inode remains allocated or not. In a normal shutdown, the answer would be "not", since the _exit for the process would close the file when it is killed, destroying the open reference and thus freeing the inode fore reuse. In the case of a normal shutdown with a directory entry diddled to point to the inode, the answer is still "not". When the FS deals with "incorrect link counts", it won't touch the file; the reason? The link count (0) is *correct*... the file is unreferenced. Whether it is allocated depends on step 6 of the fsck's defaults. The insertion of orphaned files into lost+found, and the creation of the lost+found in the root, and the resulting "off by 2" reference count for the root inode in the create case was the subject of my fsck patch. "Oops, I was wrong" will not bring back his file if he takes your advice and allows automatic fsck. It is dependent on the in core vnode reclamation list. He *needs* a reference in case the "allocated" bit has been reset (which is not the same as making it available for reallocation), and he needs a manual fsck for the same reason to allow linking the entry in. Alternately, if he has a kernel debugger, he could fake up a call to, ufs_direnter, which he would have to call the ffs_vget to get the inode by number to get the vnode pointer to get the inode data pointer to pass to direnter. He would need a storage area of 32 bits to pass to the vget, and then he would have to fake a CREATE nameidata structure pointing to the terminal component. The easiest method would be to call vget on inode 2 to get the vp for the root directory as the target directory for the direnter. This is a lot of work, and since the kernel debugger isn't there by default, his best bet would be to use a directory entry to trigger the fsck (non -y therefore non-automatic) stage 3 link count correction on the inode on disk. Again, alternately, it would be fairly trivial to write a system call to do all the work, using promiscuous knowledge of UFS structures, and then load the call, and call it (per the subject line). What I suggested before is the least effort route that provides a guarantee that the fsck won't stomp the file under any circumstances; *whenever* you do this kind of recovery, it's a good idea to run the fsck manually, anyway, so you can yes/no all of its decisions. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.