Date: Tue, 25 Jun 1996 14:14:34 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bill@twwells.com (T. William Wells) Cc: freebsd-questions@FreeBSD.ORG Subject: Re: int link(const int inode, const char *name2) Message-ID: <199606252114.OAA00722@phaeton.artisoft.com> In-Reply-To: <4qpggg$g1r@twwells.com> from "T. William Wells" at Jun 25, 96 04:00:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> : 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606252114.OAA00722>