Coda File System

Re: Coda on FreeBSD 9?

From: <>
Date: Tue, 17 Jan 2012 09:43:36 +0100
On Mon, Jan 16, 2012 at 01:55:21PM -0500, Greg Troxel wrote:
>   "coda_inactive: 0xNNNNNNNN usecount 1"

> yes, just informational as I was attempting to track something else
> down.  I think usecount is expected to be 1 when coda_inactive is
> called, and I have updated what will be NetBSD 6 to not print if it's 1.


> I dimly recall the directory issue is alignment and skipping over the
> end of 4K pages or some such.  So I did:

I guess so. BSD aligns directory entries on page boundaries
while ext2 in Linux does not.

> 1) Does coda have a directory format?  Or are directories all in
> metadata and synthesized?
> 2) When you open a directory, does venus synthesize content from some
> other format?  What format is it targetting?

Directories are stored in some internal form in RVM on the servers
but venus yields a directory in an ext2-compatible format:

struct venus_dirent {
        unsigned int    d_fileno;               /* file number of entry */
        unsigned short  d_reclen;               /* length of this record */
        unsigned char   d_type;                 /* file type, see below */
        unsigned char   d_namlen;               /* length of string in d_name */
        char            d_name[CODA_MAXNAMLEN + 1];/* name must be no longer tha
n this */

This happens to work well on Linux but probably is not handled
properly in the BSD kernel Coda code.

Apparently it is somehow handled in the ext2 in *BSD. May be this code could be
reused for the Coda module?

> 3) On an operating system, people generally should be using readdir(),
> it seems.   How does readdir() in the coda vfs implementation work?

On Linux readdir() which is a library function calls getdents() which is
a system call and returns structures (different from the ext2 format
but common for all file systems)

struct linux_dirent {
    unsigned long  d_ino;     /* Inode number */
    unsigned long  d_off;     /* Offset to next linux_dirent */
    unsigned short d_reclen;  /* Length of this linux_dirent */
    char           d_name[];  /* Filename (null-terminated) */
                        /* length is actually (d_reclen - 2 -
                           offsetof(struct linux_dirent, d_name) */
    char           pad;       // Zero padding byte
    char           d_type;    // File type (only since Linux 2.6.4;
                              // offset is (d_reclen - 1))

I guess the BSD Linux ABI layer implements getdents() in a way which breaks
differently than the BSD readdir() on the directories received from venus.

Anyway it looks like we need another layer between the directory data from venus
and the data presented to the kernel. May be venus has to be taught to align
the entries on page boundaries, which should not confuse Linux per se.

I am not familiar with this part of the code but venus/ looks like
the place to begin with.

Received on 2012-01-17 03:54:38