From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: Brent Welch <welch@panasas.com>,
NFS list <linux-nfs@vger.kernel.org>,
open-osd <osd-dev@open-osd.org>
Subject: Re: [PATCH 1/8] pnfs-obj: Remove redundant EOF from objlayout_io_state
Date: Mon, 31 Oct 2011 18:24:17 -0400 [thread overview]
Message-ID: <1320099857.10028.6.camel@lade.trondhjem.org> (raw)
In-Reply-To: <1320097506-734-1-git-send-email-bharrosh@panasas.com>
On Mon, 2011-10-31 at 14:45 -0700, Boaz Harrosh wrote:
> The EOF calculation was done on .read_pagelist(), cached
> in objlayout_io_state->eof, and set in objlayout_read_done()
> into nfs_read_data->res.eof.
>
> So set it directly into nfs_read_data->res.eof and avoid
> the extra member.
>
> This is a slight behaviour change because before eof was
> *not* set on an error update at objlayout_read_done(). But
> is that a problem? Is Generic layer so sensitive that it
> will miss the error IO if eof was set? From my testing
> I did not see such a problem.
That would probably be because the object layout will be recalled if the
file size changes on the server. If that is not the case, then you do
need eof detection...
> Which brings me to a more abstract problem. Why does the
> LAYOUT driver needs to do this eof calculation? .i.e we
> are inspecting generic i_size_read() and if spanned by
> offset + count which is received from generic layer we set
> eof. It looks like all this can/should be done in generic
> layer and not at LD. Where does NFS and files-LD do it?
> It looks like it can be promoted.
No it can't. The eof flag is returned as part of the READ4resok
structure (i.e. it is part of the READ return value) on both
read-through-mds and files-type layout reads. Basically, it allows the
server to tell you _why_ it returned a short read.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
next prev parent reply other threads:[~2011-10-31 22:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-28 19:13 [patchset 0/8] pnfs-obj: Move to ORE for v3.2 merge window Boaz Harrosh
2011-10-29 17:24 ` Trond Myklebust
2011-10-31 17:49 ` Boaz Harrosh
2011-10-31 21:34 ` Boaz Harrosh
2011-10-31 21:45 ` [PATCH 1/8] pnfs-obj: Remove redundant EOF from objlayout_io_state Boaz Harrosh
2011-10-31 22:24 ` Trond Myklebust [this message]
2011-10-31 22:45 ` Boaz Harrosh
2011-10-31 23:23 ` Boaz Harrosh
2011-10-31 23:29 ` Trond Myklebust
2011-10-31 23:59 ` Boaz Harrosh
2011-11-01 2:25 ` Trond Myklebust
2011-10-31 21:45 ` [PATCH 2/8] pnfs-obj: Return PNFS_NOT_ATTEMPTED in case of read/write_pagelist Boaz Harrosh
2011-10-31 21:47 ` [PATCH 3/8] pnfs-obj: Get rid of objlayout_{alloc,free}_io_state Boaz Harrosh
2011-10-31 22:03 ` [PATCH 4/8] pnfs-obj: Rename objlayout_io_state => objlayout_io_res Boaz Harrosh
2011-10-31 22:04 ` [PATCH 5/8] pnfs-obj: move to ore 01: ore_layout & ore_components Boaz Harrosh
2011-10-31 22:15 ` [PATCH 6/8] pnfs-obj: move to ore 02: move to ORE Boaz Harrosh
2011-10-31 22:16 ` [PATCH 7/8] pnfs-obj: move to ore 03: Remove old raid engine Boaz Harrosh
2011-10-31 22:16 ` [PATCH 8/8] pnfs-obj: Support for RAID5 read-4-write interface Boaz Harrosh
2011-11-01 17:42 ` [patchset 0/8] pnfs-obj: Move to ORE for v3.2 merge window Boaz Harrosh
2011-11-02 19:01 ` [osd-dev] " Boaz Harrosh
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=1320099857.10028.6.camel@lade.trondhjem.org \
--to=trond.myklebust@netapp.com \
--cc=bharrosh@panasas.com \
--cc=linux-nfs@vger.kernel.org \
--cc=osd-dev@open-osd.org \
--cc=welch@panasas.com \
/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).