The Linux Kernel Mailing List
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox