qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [V9fs-developer] [PATCH] virtio-9p: getattr server


From: Venkateswararao Jujjuri (JV)
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
User-agent: Thunderbird 2.0.0.24 (Windows/20100228)

Aneesh Kumar K. V wrote:
> On Thu, 3 Jun 2010 18:29:02 +0530, Sripathi Kodi <address@hidden> wrote:
>> On Wed, 02 Jun 2010 19:49:24 +0530
>> "Aneesh Kumar K. V" <address@hidden> wrote:
>>
>>> On Fri, 28 May 2010 16:08:43 +0530, Sripathi Kodi <address@hidden> wrote:
>>>> From: M. Mohan Kumar <address@hidden>
>>>>
>>>> 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
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]