From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54646 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OKYND-0002og-13 for qemu-devel@nongnu.org; Fri, 04 Jun 2010 10:59:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OKYNB-0002k3-L9 for qemu-devel@nongnu.org; Fri, 04 Jun 2010 10:59:50 -0400 Received: from e38.co.us.ibm.com ([32.97.110.159]:58962) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OKYNB-0002jr-F3 for qemu-devel@nongnu.org; Fri, 04 Jun 2010 10:59:49 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o54ErC7i016463 for ; Fri, 4 Jun 2010 08:53:12 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o54Exi9T263616 for ; Fri, 4 Jun 2010 08:59:45 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o54ExiP6026662 for ; Fri, 4 Jun 2010 08:59:44 -0600 Message-ID: <4C0914DE.3050800@linux.vnet.ibm.com> Date: Fri, 04 Jun 2010 07:59:42 -0700 From: "Venkateswararao Jujjuri (JV)" MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [V9fs-developer] [PATCH] virtio-9p: getattr server implementation for 9P2000.L protocol. References: <20100528103843.4938.29265.stgit@localhost.localdomain> <87iq61frf7.fsf@linux.vnet.ibm.com> <20100603182902.2551f814@in.ibm.com> <87r5kntd54.fsf@linux.vnet.ibm.com> In-Reply-To: <87r5kntd54.fsf@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Aneesh Kumar K. V" Cc: v9fs-developer@lists.sourceforge.net, Sripathi Kodi , qemu-devel@nongnu.org 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. Thanks, JV > > > -aneesh >