milko question

[Jack Neely]

Love,

My reason for wanting to do this is because I have harddrive images of an
AFS server but I don't have access to an AFS server to read the data.  It
would be very nice if I could salvage the data.

Jack Neely



--
Jack Neely  jjneely at eos.ncsu.edu
Student in Computer Science
   at North Carolina State University

Current Project: The NC State Linux Video Project
   http://prisant.ncsu.edu/~neely
WWW Pages:
   http://www.ac.net/~hneely
   http://quackmaster.net
PGP Public Key:
   http://quackmaster.net/pgp.html

On 11 Mar 2000, Love wrote:

> Jack Neely <jjneely at eos.ncsu.edu> writes:
> 
> > Hey all!
> > 
> > I few questions about milko.  Can milko read an AFS 3.4 server volume?
> 
> On disk, no.
> 
> > Is the format of the data files that make up an AFS volume known?
> 
> Not really, but by reading the old afs papers and the header-files I belive
> it orginized something like this:
> 
> /vicepN/vol<vol# padded to 8 har> Contain inode-number of the SmallVnode
>   inode (files and symlinks), LargeVnode inode (dirs, it has acls), and
>   some summery infomation inode is some order (or just a pointer to a inode
>   with summery infomation, doesn't really matter).
> 
> The SmallVnode contain the on-disk equvalent of a AFSFetchStatus + a inode
> number. LargeVnode the same + AFSOpaque for acl. Don't know how store the
> bits. It might be that the acl is stored now in a separete inode, but I
> don't know.
> 
> All inodes created is taged with extra information (the the volume the
> belong to and some other things I don't know) in the inode. This is a
> source of pain for transarc (and their users). Resently Digital/Compaq
> decided (with osf 4.0d) to use to more fields in the inode (32 bits support
> for UID and GID). Then they use the one of the fields transarc stored some
> info. The kernel "corrected" any "bad" inodes it would find. Fsck did the
> same. Not fun at all. A usual it took transarc half a year to fix the
> problem (we had the source to osf and backed out Digital\s changes).
> 
> I'm not really sure its that interesting to know in more detail how they
> did it, but if some care I wouldn't mind to know more. (Please don't turn
> the world upside down to find it the info, we will do diffrently anyway).
> 
> Why do you want to read the ondisk bits ? 
> 
> Just do a vos backup | vos restore. The dump format isn't known, but its
> easier to figure out.
> 
> Love
>