[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [V9fs-developer] [PATCH] virtio-9p: getattr server
From: |
Aneesh Kumar K. V |
Subject: |
Re: [Qemu-devel] Re: [V9fs-developer] [PATCH] virtio-9p: getattr server implementation for 9P2000.L protocol. |
Date: |
Sat, 05 Jun 2010 19:11:53 +0530 |
User-agent: |
Notmuch/ (http://notmuchmail.org) Emacs/24.0.50.1 (i686-pc-linux-gnu) |
On Fri, 04 Jun 2010 07:59:42 -0700, "Venkateswararao Jujjuri (JV)"
<address@hidden> wrote:
> 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.
>
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