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
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;
}
On 11/1/05, Jeff V. Merkey <[email protected]> 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.
>
> 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
>
As defined in include/linux/ext3_fs.h:
/*
* Special inodes numbers
*/
#define EXT3_ROOT_INO 2 /* Root inode */
Cheers,
Jan