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;
}
next prev parent 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