From owner-freebsd-fs  Mon Jan  3 10:27:14 2000
Delivered-To: freebsd-fs@freebsd.org
Received: from aplcenMP.apl.jhu.edu (apl.jhu.edu [128.220.101.100])
	by hub.freebsd.org (Postfix) with ESMTP id 9C46A1506A
	for <freebsd-fs@freebsd.org>; Mon,  3 Jan 2000 10:27:07 -0800 (PST)
	(envelope-from mccrobi@aplcenMP.apl.jhu.edu)
Received: (from mccrobi@localhost)
	by aplcenMP.apl.jhu.edu (8.9.3/8.9.1) id NAA11389
	for freebsd-fs@freebsd.org; Mon, 3 Jan 2000 13:27:54 -0500 (EST)
Date: Mon, 3 Jan 2000 13:27:54 -0500 (EST)
From: Mccrobie Charles Arn <mccrobi@aplcenMP.apl.jhu.edu>
Message-Id: <200001031827.NAA11389@aplcenMP.apl.jhu.edu>
Content-Type: text
Sender: owner-freebsd-fs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Hello,

I have some questions about file systems under FreeBSD.

1)  I want to keep a vnode reference in the FS mount private data.
    How does the file system avoid having "reclaim" called on this vnode?
    Do I need to tract the "state" of the vnode and recreate it if its
    reclaimed?

    What I'm doing is writing a file system for read-only of OpenVMS ODS-2.
    ODS-2 has a file called the INDEXF.SYS file which contains all the
    file headers (vnodes) for the file system.  I would like to keep the
    INDEXF.SYS file open all the time so that I can perform VOP_BMAP on it
    to translate logical blocks into physical blocks.

    For those non-OpenVMS'ers, the file header (vnode) can be obtained from
    the file number (inode number) by performing a logical->physical block
    translation on the INDEXF.SYS file.  (Incidently, OpenVMS VBN=Unix LBN
    and OpenVMS LBN=Unix physical block).

    struct ods2_mount
    {
        ...
        vnode *indexf;
    }

    ods2_vget( ... )
    {
        ...
        header_vbn = ... /* convert file number to vbn within INDEXF.SYS */
        error = VOP_BMAP(indexf, vbn, NULL, &lbn, ...);
        ...
    }

2)  The above defers the LBN->physical mapping to the VOP_BMAP procedure.  Is
    this the "preferred" method or should I just perform that mapping through
    use of a "private" procedure?

    The CD9660 code uses the VOP_BMAP procedure.

    The HP UDF code keeps a private procedure for performing the mapping.  The
    VOP_BMAP call simply returns an error.

3)  It seems the CD9660 file system doesn't do the following:

    a)  Handle interleaved files.  I found nothing in the BMAP that accounts
        for file gap.  Furthermore, only the header contains file_unit_size
        and interleave.  I assume no data CD's have been produced with
        interleaved files.  Just the same, it does seem to be an oversight...

    b)  Handle multi-extent files.  As I understand ISO 9660, there may be
        more than one entry for a file which differs only in the "multi extent
        flag" being set.  This allows for multiple non-contiguous extents for
        a single file.  Again, I found no references to "multi extents" in the
        code.  Am I missing something here?

Thanks,

Chuck McCrobie  (** MAD VAX **)



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message