Date: Sat, 1 Aug 1998 02:43:41 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: raju@rssd.hk.olivetti.com (Raju M. Daryanani) Cc: tlambert@primenet.com, mystify@wkstn4-208.lxr.georgetown.edu, freebsd-fs@FreeBSD.ORG Subject: Re: Trying to recover lost file Message-ID: <199808010243.TAA04462@usr06.primenet.com> In-Reply-To: <199808010148.JAA09234@olibbs.hk.olivetti.com> from "Raju M. Daryanani" at Aug 1, 98 09:48:32 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808010243.TAA04462>