All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jeff V. Merkey" <jmerkey@utah-nac.org>
To: "Jeff V. Merkey" <jmerkey@utah-nac.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.9 VFS Issues
Date: Tue, 01 Nov 2005 15:49:42 -0700	[thread overview]
Message-ID: <4367F106.4070305@utah-nac.org> (raw)
In-Reply-To: <4367F06B.2050209@utah-nac.org>

Jeff V. Merkey wrote:

>
> I have noticed one change from 2.4 to 2.6 which although esoteric, is 
> bothersome.  Did the dache assign static inode identities to
> the "." and ".." directories for 2.6 differnt than the behavior in 
> 2.4?  I notice that the root of ext based filesystems is now always "2"
> for the root (although readdir commands pass "0" during passes through 
> the readdir function calls into the VFS).  I have noticed that
> the user space libs always fix "2" as the value of the inode for the 
> root directory.  I am having trouble getting the . and .. entries to show
> up under 2.6, although, they seem to work just fine when you type cd 
> .. and cd ., etc.
>
> I am using my DSFS file system and I am generating inode numbers 
> dynamically for captured data, but I am seeing problems with readdir 
> calls
> from a program I wrote called "dir.c" (ATTACHED) I am using to debug.  
> Anyone know what changed in 2.6.9 and later
> kernels that is causing this, and is there some assummption I need to 
> make?  I also have noted that the . and .. entries are no longer
> passed (or at least do not appear to be getting passed) through to the 
> VFS layer from the dcache.  The DSFS works just fine but this
> issue is somewhat bothersome and I would like to know what is wrong 
> here as it may be exposing some other problem in the VFS
> (apart from wetware issues).
>
> Here's what dir.c outputs from user space for ext3 FS's:
>
> . type-4 len-16 ino-00000002 off-0000000C
> .. type-4 len-16 ino-00000002 off-00000018
> lost+found type-4 len-24 ino-0000000B off-0000002C
> grub type-4 len-16 ino-00000FC1 off-00000038
> initrd-2.6.5-1.358.img type-8 len-40 ino-0000001D off-00000058
> bzImage type-8 len-24 ino-00000010 off-00000078
> boot.b type-8 len-24 ino-00000011 off-00000088
> chain.b type-8 len-24 ino-0000000E off-00000098
> os2_d.b type-8 len-24 ino-0000000F off-000000A8
> vmlinuz-2.6.9 type-8 len-32 ino-00000012 off-00000150
> kernel.h type-8 len-24 ino-00000019 off-000001FC
> System.map-2.6.5-1.358 type-8 len-40 ino-0000000C off-0000021C
> config-2.6.5-1.358 type-8 len-32 ino-0000000D off-00000238
> vmlinuz-2.6.5-1.358 type-8 len-32 ino-0000001C off-00000400
>
>
>
> Here's what dir.c outputs from user space for DSFS (I assign inode 
> numbers dynamically, however, the data files are fixed in the FS 
> beneath).  The . and .. entries are always missing.
>
> stats type-4 len-24 ino-00008001 off-00000003
> slots type-4 len-24 ino-00008002 off-00000004
> slice type-4 len-24 ino-00008003 off-00000005
> merge type-4 len-24 ino-00008004 off-00000006
> create type-4 len-24 ino-00008005 off-00000007
> 1-lo type-8 len-16 ino-10000005 off-0000000B
> 5-eth0 type-8 len-24 ino-10000009 off-00000027
> 1-lo-slice type-8 len-24 ino-20000025 off-0000002B
> 5-eth0-slice type-8 len-24 ino-20000029 off-00000046
>
>
>
> Here's the dir.c source code I wrote to test this:
>
> #include <unistd.h>
> #include <dirent.h>
>
> int main(int argc, char *argv[])
> {
>     register struct dirent *entry;
>     DIR *local_dir;
>
>         if (argc < 2)
>         {
>               printf("USAGE:  dir <directory>\n");
>               return 1;
>         }
>
>         if ((local_dir = opendir(argv[1])) == NULL)
>             return 1;
>
>         while ((entry = readdir(local_dir)) != NULL)
>        {
>             printf("%s type-%d len-%d ino-%08X off-%08X\n",
>                    entry->d_name,                        
> (int)entry->d_type,                       (int)entry->d_reclen,     
>                   (unsigned)entry->d_ino,                       
> (unsigned)entry->d_off);
>         }
>         closedir(local_dir);
>
>         return 0;
> }
>
> Any ideas?
>
> Jeff
>
And here's the readdir code I use in DSFS to create the entries:

int solera_dir_readdir(struct file *filp, void *dirent, filldir_t filldir)
{
    register ULONG i, count = 0, retCode;
    struct inode *inode = filp->f_dentry->d_inode;
    struct dentry *dentry = filp->f_dentry;
#if LINUX_26
    register DISK_SPACE_RECORD *d =
             (DISK_SPACE_RECORD *) inode->i_sb->s_fs_info;
#else
    register DISK_SPACE_RECORD *d =
             (DISK_SPACE_RECORD *) inode->i_sb->u.generic_sbp;
#endif
    BYTE name[MAX_NAME_LENGTH];
    ULONG ino = 0, namelen = 0, type = DT_UNKNOWN;

#if VERBOSE   
    P_Print("readdir called\n");
#endif

    if (!inode || !S_ISDIR(inode->i_mode))
       return -ENOTDIR;

    i = filp->f_pos;
    switch (i)
    {
       case 0:
      if (filldir(dirent, ".",  1, 0, inode->i_ino, DT_DIR) < 0)
         goto readdir_end;
      filp->f_pos = 1;
          count++;

       case 1:
      if (filldir(dirent, "..", 2, 1, parent_ino(dentry), DT_DIR) < 0)
         goto readdir_end;
      filp->f_pos = 2;
          count++;

       default:
          while (1)
          {
             name[0] = '\0';
             retCode = get_directory_entry(d, inode->i_ino, (filp->f_pos 
- 2),
                                     name, &namelen, &ino, &type);
             if (retCode == -2) 
             {
                filp->f_pos++;
                continue;
             }

#if FS_VERBOSE
             P_Print("%s (%d) ino-%u count=%d pos1-%d pos2-%d\n",
                    name, (int)namelen, (unsigned int)ino,
                    (int)count, (int)i, (int)filp->f_pos);
#endif

             if (retCode)
                break;

             if (filldir(dirent, name, namelen, filp->f_pos,
                         ino, type) < 0)
            goto readdir_end;

             filp->f_pos++;
         count++;
          }
          break;
    }

readdir_end:;

#if FS_VERBOSE
    P_Print("readdir count=%d pos1-%d pos2-%d\n", (int)count,
             (int)i, (int)filp->f_pos);
#endif

    return count;
}



  reply	other threads:[~2005-11-02  0:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-01 22:47 2.6.9 VFS Issues Jeff V. Merkey
2005-11-01 22:49 ` Jeff V. Merkey [this message]
2005-11-02 10:55 ` Jan Blunck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4367F106.4070305@utah-nac.org \
    --to=jmerkey@utah-nac.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.