Date: Mon, 29 Oct 2001 06:52:39 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Sheldon Hearn <sheldonh@starjuice.net> Cc: Martijn Lina <martijn@medialab.lostboys.nl>, Thomas Beauchamp <robotomas2001@yahoo.co.uk>, freebsd-security@FreeBSD.ORG Subject: Re: recovery from 'rm -rf /' Message-ID: <20011029065239.F75481@gsmx07.alcatel.com.au> In-Reply-To: <64563.1002193406@axl.seasidesoftware.co.za>; from sheldonh@starjuice.net on Thu, Oct 04, 2001 at 01:03:26PM %2B0200 References: <20011003223038.G28329@medialab.lostboys.nl> <64563.1002193406@axl.seasidesoftware.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 04, 2001 at 01:03:26PM +0200, Sheldon Hearn wrote: > > >On Wed, 03 Oct 2001 22:30:38 +0200, Martijn Lina wrote: > >> first of all, be sure that absolutely nothing is writing to the disk >> anymore. the inodes that have been freed last, will be the first to be >> used again. > >Are you sure about that? Prior to FFS, freed disk blocks went into a LIFO list so the last freed block would be the first allocated. A limited number (~100) of freed inodes are cached in the super-block (further freed inodes were just released). This means that new inodes would be allocated from roughly the 100 first deleted files in reverse order (additional inodes would be be allocated by searching the inode list for free inodes). With FFS, I'm not so certain. The following is based on a quick study of /sys/ufs/ffs/ffs_alloc.c - a FS guru might like to confirm it. The last freed inode may possibly be the first re-allocated inode (it's not immediately clear to me). Further inodes are allocated by a mixture of searching linearly through the free inode bitmap in a cylinder group and hashing between CGs. Likewise, the last release block may be cached, but further blocks are allocated by searching as before (potentially modified by rotational position). Soft-updates further confuses the issue - the dependency graph and write-behind means that the most-recently deleted file (blocks or inode) won't be available for immediate re-allocation. That said, avoiding writing anything to disk is good advice. If the other filesystems are clean and the mistake is noticed quickly, I'd even suggest using the reset button to avoid the sync-on-unmount (and not fsck'ing that filesystem after rebooting). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011029065239.F75481>