From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60319 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OKSGq-0006JX-Ot for qemu-devel@nongnu.org; Fri, 04 Jun 2010 04:28:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OKSGo-00054H-Ds for qemu-devel@nongnu.org; Fri, 04 Jun 2010 04:28:52 -0400 Received: from e28smtp05.in.ibm.com ([122.248.162.5]:37765) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OKSGm-00053P-E9 for qemu-devel@nongnu.org; Fri, 04 Jun 2010 04:28:50 -0400 Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by e28smtp05.in.ibm.com (8.14.4/8.13.1) with ESMTP id o548SeXv032265 for ; Fri, 4 Jun 2010 13:58:40 +0530 Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o548SdRr3354838 for ; Fri, 4 Jun 2010 13:58:39 +0530 Received: from d28av02.in.ibm.com (loopback [127.0.0.1]) by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o548SdZE022597 for ; Fri, 4 Jun 2010 18:28:39 +1000 From: "Aneesh Kumar K. V" In-Reply-To: <20100603182902.2551f814@in.ibm.com> References: <20100528103843.4938.29265.stgit@localhost.localdomain> <87iq61frf7.fsf@linux.vnet.ibm.com> <20100603182902.2551f814@in.ibm.com> Date: Fri, 04 Jun 2010 13:58:39 +0530 Message-ID: <87r5kntd54.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Re: [V9fs-developer] [PATCH] virtio-9p: getattr server implementation for 9P2000.L protocol. List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sripathi Kodi Cc: v9fs-developer@lists.sourceforge.net, qemu-devel@nongnu.org On Thu, 3 Jun 2010 18:29:02 +0530, Sripathi Kodi wrote: > On Wed, 02 Jun 2010 19:49:24 +0530 > "Aneesh Kumar K. V" wrote: > > > On Fri, 28 May 2010 16:08:43 +0530, Sripathi Kodi wrote: > > > From: M. Mohan Kumar > > > > > > 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. -aneesh