Re: [Qemu-devel] Re: [V9fs-developer] [PATCH] virtio-9p: getattr server implementation for 9P2000.L protocol.

["Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>]

On Fri, 04 Jun 2010 07:59:42 -0700, "Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com> wrote:
> Aneesh Kumar K. V wrote:
> > On Thu, 3 Jun 2010 18:29:02 +0530, Sripathi Kodi <sripathik@in.ibm.com> wrote:
> >> On Wed, 02 Jun 2010 19:49:24 +0530
> >> "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> >>
> >>> On Fri, 28 May 2010 16:08:43 +0530, Sripathi Kodi <sripathik@in.ibm.com> wrote:
> >>>> From: M. Mohan Kumar <mohan@in.ibm.com>
> >>>>
> >>>> SYNOPSIS
> >>>>
> >>>>       size[4] Tgetattr tag[2] fid[4]
> >>>>
> >>>>       size[4] Rgetattr tag[2] lstat[n]
> >>>>
> >>>>    DESCRIPTION
> >>>>
> >>>>       The getattr transaction inquires about the file identified by fid.
> >>>>       The reply will contain a machine-independent directory entry,
> >>>>       laid out as follows:
> >>>>
> >>>>          qid.type[1]
> >>>>             the type of the file (directory, etc.), represented as a bit
> >>>>             vector corresponding to the high 8 bits of the file's mode
> >>>>             word.
> >>>>
> >>>>          qid.vers[4]
> >>>>             version number for given path
> >>>>
> >>>>          qid.path[8]
> >>>>             the file server's unique identification for the file
> >>>>
> >>>>          st_mode[4]
> >>>>             Permission and flags
> >>>>
> >>>>          st_nlink[8]
> >>>>             Number of hard links
> >>>>
> >>>>          st_uid[4]
> >>>>             User id of owner
> >>>>
> >>>>          st_gid[4]
> >>>>             Group ID of owner
> >>>>
> >>>>          st_rdev[8]
> >>>>             Device ID (if special file)
> >>>>
> >>>>          st_size[8]
> >>>>             Size, in bytes
> >>>>
> >>>>          st_blksize[8]
> >>>>             Block size for file system IO
> >>>
> >>> So it should be scaled by iounit right ? If we say 9p block size is iounit.
> >> Yes, I think it should be iounit. Currently st_blksize being returned
> >> in stat structure to the user space does not use this field that comes
> >> from the server. It is being calculated as follows in
> >> generic_fillattr():
> >>
> >>         stat->blksize = (1 << inode->i_blkbits);
> >>
> >> So there may not be a need to put st_blksize on the protocol. Further,
> >> inode->i_blkbits is copied from sb->s_blocksize_bits. For 9P this value
> >> is obtained as:
> > 
> > That is what linux kernel currently does. But from the protocol point of
> > view and not looking at specific linux implementation i would suggest to
> > put st_blksize on wire. 
> 
> This is part of .L protocol. Specifically for Linux systems. So, if Linux is already
> doing it, I don't think we need to repeat it.
> 

But nothing prevents from changing Linux internal implementation. So we
can't depend on Linux kernel internal implementation. Later in 2.6.x we
may not derive stat->blksize from inode->i_blkbits at all. So we cannot
depend on Linux kernel internal implementation.

-aneesh