Hi,
We are writing a stackable file system. While testing this on NFS we
came across a situation where sometimes we are getting ASCII NUL bytes
in the buffer read from the lower file system (NFS in this case). This
happens when NFS client 1 is writing to a file and NFS client 2 is
continuously reading from the same file. A simple case like the
following also shows the same problem
----------------8<------------------8<-----------------------------
while (1)
{
if (vfs_getattr(filp->f_vfsmnt, filp->f_dentry, &stat) != 0)
{
printk(KERN_INFO "Error in getting attribute\n");
break;
}
if (no_inc == 60)
{
printk(KERN_INFO "File not increased for 1 min. Quitting\n");
break;
}
inc = stat.size - old_size;
if (inc)
{
old_size = stat.size;
no_inc = 0;
count = vfs_read(filp, buf,
sizeof(buf), &filp->f_pos);
if (count < 0)
{
printk(KERN_INFO "Error in reading file\n");
goto out;
}
printk(KERN_INFO "File increase = [%llu], total read = [%llu]"
" file_len = [%llu] File size from inode
= [%llu]\n",
inc, count, stat.size,
i_size_read(filp->f_dentry->d_inode));
printk(KERN_INFO
"----------------------------------------------------\n");
debug_dump("Read buffer", buf, total_count);
}
else
{
no_inc++;
}
}
----------------8<------------------8<-----------------------------
We have also noticed that the expected increase (inc) and the size
returned in (vfs_read()) is different. A similar program in user space
also reproduces this issue. A google search for this issue tells me
that others have seen this issue as well.
http://stackoverflow.com/questions/6814404/java-inputstream-read-methods-returning-ascii-nul-characters-for-file-in-a-nfs
Is this a known and expected behaviour of NFS?
PS : This is a very old kernel (2.6.18.274.) We still have to support RHEL 5 :)
--
Regards,
Ranjan
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
