From: "Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com>
To: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: v9fs-developer@lists.sourceforge.net,
Sripathi Kodi <sripathik@in.ibm.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [V9fs-developer] [PATCH] virtio-9p: getattr server implementation for 9P2000.L protocol.
Date: Fri, 04 Jun 2010 07:59:42 -0700 [thread overview]
Message-ID: <4C0914DE.3050800@linux.vnet.ibm.com> (raw)
In-Reply-To: <87r5kntd54.fsf@linux.vnet.ibm.com>
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.
Thanks,
JV
>
>
> -aneesh
>
next prev parent reply other threads:[~2010-06-04 14:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-28 10:38 [Qemu-devel] [PATCH] virtio-9p: getattr server implementation for 9P2000.L protocol Sripathi Kodi
2010-06-02 14:19 ` [Qemu-devel] Re: [V9fs-developer] " Aneesh Kumar K. V
2010-06-03 12:59 ` Sripathi Kodi
2010-06-04 8:28 ` Aneesh Kumar K. V
2010-06-04 14:59 ` Venkateswararao Jujjuri (JV) [this message]
2010-06-05 13:41 ` Aneesh Kumar K. V
2010-06-07 10:34 ` Sripathi Kodi
2010-06-07 12:28 ` [V9fs-developer] [Qemu-devel] " Sripathi Kodi
2010-07-01 5:31 ` [Qemu-devel] Re: [V9fs-developer] " Aneesh Kumar K. V
2010-07-01 8:56 ` Sripathi Kodi
2010-07-01 12:41 ` Aneesh Kumar K. V
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C0914DE.3050800@linux.vnet.ibm.com \
--to=jvrao@linux.vnet.ibm.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=sripathik@in.ibm.com \
--cc=v9fs-developer@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).