From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55026 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OKteC-00037Y-JS for qemu-devel@nongnu.org; Sat, 05 Jun 2010 09:42:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OKteB-0005mC-Ep for qemu-devel@nongnu.org; Sat, 05 Jun 2010 09:42:48 -0400 Received: from e28smtp07.in.ibm.com ([122.248.162.7]:43168) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OKteA-0005lG-PX for qemu-devel@nongnu.org; Sat, 05 Jun 2010 09:42:47 -0400 Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by e28smtp07.in.ibm.com (8.14.4/8.13.1) with ESMTP id o55Dgdjj012334 for ; Sat, 5 Jun 2010 19:12:39 +0530 Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o55DgTFa3133490 for ; Sat, 5 Jun 2010 19:12:39 +0530 Received: from d28av01.in.ibm.com (loopback [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o55DgSLe026163 for ; Sat, 5 Jun 2010 19:12:28 +0530 From: "Aneesh Kumar K. V" Subject: Re: [Qemu-devel] Re: [V9fs-developer] [PATCH] virtio-9p: getattr server implementation for 9P2000.L protocol. In-Reply-To: <4C0914DE.3050800@linux.vnet.ibm.com> References: <20100528103843.4938.29265.stgit@localhost.localdomain> <87iq61frf7.fsf@linux.vnet.ibm.com> <20100603182902.2551f814@in.ibm.com> <87r5kntd54.fsf@linux.vnet.ibm.com> <4C0914DE.3050800@linux.vnet.ibm.com> Date: Sat, 05 Jun 2010 19:11:53 +0530 Message-ID: <87r5kly4ta.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Venkateswararao Jujjuri (JV)" Cc: v9fs-developer@lists.sourceforge.net, Sripathi Kodi , qemu-devel@nongnu.org On Fri, 04 Jun 2010 07:59:42 -0700, "Venkateswararao Jujjuri (JV)" wrote: > Aneesh Kumar K. V wrote: > > 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. > > 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