Re: Oddity in libufs.
On Saturday 24 September 2005 11:26 pm, Frank Mayhar wrote:
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
other bits and pieces to maybe get it suitable for release into the
wild. I just looked at cgread() to see what it does and noticed that
there seems to be a redundant line:
.
.
if (c = fs-fs_ncg) {
return (0);
}
ccg = fsbtodb(fs, cgtod(fs, c)) * disk-d_bsize;
if (bread(disk, fsbtodb(fs, cgtod(fs, c)),
disk-d_cgunion.d_buf,
.
.
That assignment up there looks redundant, as ccg is never used. I
suspect that it's a relic of an old lseek()/read() pair that's long
gone.
The person you probably want to ask is [EMAIL PROTECTED] I can't find anything
in
cvs annotate or in the p4 depot to give history on how that got there. On
the face of it, it looks like it shouldn't cause any harm to just remove ccg.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve = http://www.FreeBSD.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Oddity in libufs.
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? (Er, and, why python, of all things?) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Oddity in libufs.
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.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Oddity in libufs.
On 2005-09-24 20:26, Frank Mayhar [EMAIL PROTECTED] wrote:
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
other bits and pieces to maybe get it suitable for release into the
wild. I just looked at cgread() to see what it does and noticed that
there seems to be a redundant line:
.
.
if (c = fs-fs_ncg) {
return (0);
}
ccg = fsbtodb(fs, cgtod(fs, c)) * disk-d_bsize;
if (bread(disk, fsbtodb(fs, cgtod(fs, c)), disk-d_cgunion.d_buf,
.
.
That assignment up there looks redundant, as ccg is never used. I
suspect that it's a relic of an old lseek()/read() pair that's long
gone.
It's probably easy to verify that without this assignment 'ccg' is an
unused var:
- Comment it out
- Rebuild with an elevated WARNS level
if a warning about 'unused ccg var' is printed, then you are certain
that ccg was only used for the assignment.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Oddity in libufs.
On Sun, 2005-09-25 at 14:00 +0300, Giorgos Keramidas wrote: On 2005-09-24 20:26, Frank Mayhar [EMAIL PROTECTED] wrote: That assignment up there looks redundant, as ccg is never used. I suspect that it's a relic of an old lseek()/read() pair that's long gone. It's probably easy to verify that without this assignment 'ccg' is an unused var: Um, yeah. I was pointing it out mostly so that a committer could check it out and perhaps remove the line in question... -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Oddity in libufs.
On 2005-09-25 14:00, Giorgos Keramidas [EMAIL PROTECTED] wrote:
On 2005-09-24 20:26, Frank Mayhar [EMAIL PROTECTED] wrote:
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
other bits and pieces to maybe get it suitable for release into the
wild. I just looked at cgread() to see what it does and noticed that
there seems to be a redundant line:
.
.
if (c = fs-fs_ncg) {
return (0);
}
ccg = fsbtodb(fs, cgtod(fs, c)) * disk-d_bsize;
if (bread(disk, fsbtodb(fs, cgtod(fs, c)), disk-d_cgunion.d_buf,
.
.
That assignment up there looks redundant, as ccg is never used. I
suspect that it's a relic of an old lseek()/read() pair that's long
gone.
It's probably easy to verify that without this assignment 'ccg' is an
unused var:
- Comment it out
- Rebuild with an elevated WARNS level
if a warning about 'unused ccg var' is printed, then you are certain
that ccg was only used for the assignment.
FWIW,
libufs built with the following patch seems to pass at least a build
test fine, even with WARNS=6
%%%
Index: cgroup.c
===
RCS file: /home/ncvs/src/lib/libufs/cgroup.c,v
retrieving revision 1.3
diff -u -r1.3 cgroup.c
--- cgroup.c9 Jun 2003 09:32:29 - 1.3
+++ cgroup.c26 Sep 2005 02:09:07 -
@@ -55,14 +55,12 @@
cgread1(struct uufsd *disk, int c)
{
struct fs *fs;
- off_t ccg;
fs = disk-d_fs;
if (c = fs-fs_ncg) {
return (0);
}
- ccg = fsbtodb(fs, cgtod(fs, c)) * disk-d_bsize;
if (bread(disk, fsbtodb(fs, cgtod(fs, c)), disk-d_cgunion.d_buf,
fs-fs_bsize) == -1) {
ERROR(disk, unable to read cylinder group);
%%%
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Oddity in libufs.
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/ -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Oddity in libufs.
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
other bits and pieces to maybe get it suitable for release into the
wild. I just looked at cgread() to see what it does and noticed that
there seems to be a redundant line:
.
.
if (c = fs-fs_ncg) {
return (0);
}
ccg = fsbtodb(fs, cgtod(fs, c)) * disk-d_bsize;
if (bread(disk, fsbtodb(fs, cgtod(fs, c)),
disk-d_cgunion.d_buf,
.
.
That assignment up there looks redundant, as ccg is never used. I
suspect that it's a relic of an old lseek()/read() pair that's long
gone.
--
Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/
Exit Consulting http://www.gpsclock.com/
http://www.exit.com/blog/frank/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
