From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 27 03:08:35 2005 Return-Path: X-Original-To: FreeBSD-hackers@freebsd.org Delivered-To: FreeBSD-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82E5A16A41F for ; Tue, 27 Sep 2005 03:08:35 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD5D043D4C for ; Tue, 27 Sep 2005 03:08:34 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id j8R384V2077832; Mon, 26 Sep 2005 20:08:04 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id j8R383aU077831; Mon, 26 Sep 2005 20:08:03 -0700 (PDT) (envelope-from jmg) Date: Mon, 26 Sep 2005 20:08:03 -0700 From: John-Mark Gurney To: Frank Mayhar Message-ID: <20050927030803.GB716@funkthat.com> Mail-Followup-To: Frank Mayhar , FreeBSD-hackers@freebsd.org References: <1127618793.38683.9.camel@realtime.exit.com> <20050926042315.GA716@funkthat.com> <1127776298.10212.1.camel@realtime.exit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1127776298.10212.1.camel@realtime.exit.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: FreeBSD-hackers@freebsd.org Subject: Re: Oddity in libufs. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 03:08:35 -0000 Frank Mayhar wrote this message on Mon, Sep 26, 2005 at 16:11 -0700: > On Sun, 2005-09-25 at 21:23 -0700, John-Mark Gurney wrote: > > Frank Mayhar wrote this message on Sat, Sep 24, 2005 at 20:26 -0700: > > > I've been using libufs as the I/O mechanism for my (heavy) modification > > > of sysutils/ffsrecov. It's working to my needs and now I'm poking at > > > > Well, I've recently rewrote ffsrecov in python, and have put up a > > preliminary copy up at: > > http://people.freebsd.org/~jmg/ffsrecov/ > > Sigh. Of _course_ you have. Where were you in June when I was begging > for this? busy doing other stuff... (and not having a HD failure, and then a failure of the backup disk, which somehow managed to shift the blocks containing the root inode and a few inodes after it 8 bytes, yes bytes, later in the disk)... which got/made me rewrite ffsrecov... > (Er, and, why python, of all things?) Well, partly because python makes it easier to be an interactive recovery utility... Like my backup disk, I don't know how it happened but inodes 2 through 16 (the only ones allocated in the first cg) for some reason were shifted 8 bytes later on the disk... w/ C, that'd of been very difficult to fix, but using interactive python it made it easy: import block import ffsrecov b = block.Block(open('/dev/da0')) f = ffsrecov.FFS(b) print repr(f['/']) # hmmm, root inode is messed up inodeblk = f.getblock(f.ino_to_fsba(2)) print repr(inodeblk[:512]) # print out the first sector inodeblk = inodeblk[8:] # drop the first 8 bytes tmpinodes = [ ffsrecov.FFSInode(fs, i, inodeblk[i * 256: (i + 1) * 256]) for i in range(2, 17) ] # generate inodes filter(lambda x: f.inodes.__setitem__(x.ino, x), tmpinodes) # put them in the cache (f.inodes is a WeakValueDictionary) print f['/'] # wow, things are much better! print map(None, f['/']) # now I can see the other file entries It lets me do things like make use of the WeakValueDictionary for inodes (cache the inode as long as the program keeps a reference to it), along with garbage collection... plus, I don't ever have to worry about messing up pointers and getting a crash (which I had in my earlier version of ffsrecov)... also, it only took me a weekend to write... The real big thing is that I don't have to worry about the differences between ufs1_daddr_t and ufs2_daddr_t, and w/ the classes, lets me treat inodes from both UFS1 and UFS2 exactly the same... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."