Oddity in libufs.

[John-Mark Gurney]

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."