qemu-devel
[Top][All Lists]
Advanced

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

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


From: Aneesh Kumar K. V
Subject: [Qemu-devel] Re: [V9fs-developer] [PATCH] virtio-9p: getattr server implementation for 9P2000.L protocol.
Date: Fri, 04 Jun 2010 13:58:39 +0530
User-agent: Notmuch/ (http://notmuchmail.org) Emacs/24.0.50.1 (i686-pc-linux-gnu)

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. 


-aneesh



reply via email to

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