All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Peng Tao <bergwolf@gmail.com>
Cc: <Trond.Myklebust@netapp.com>, <linux-nfs@vger.kernel.org>,
	<bhalevy@tonian.com>
Subject: Re: [PATCH 0/4] nfs41: allow layoutget at pnfs_do_multiple_writes
Date: Tue, 29 Nov 2011 13:50:17 -0800	[thread overview]
Message-ID: <4ED55399.4060707@panasas.com> (raw)
In-Reply-To: <4ED54FE4.9050008@panasas.com>

On 11/29/2011 01:34 PM, Boaz Harrosh wrote:
> But just do the above and you'll see that it is perfect.
> 
> BTW don't limit the lo_segment size by the max_io_size. This is why you
> have .bg_test to signal when IO is maxed out.
> 
> - The read segments should be as big as possible (i_size long)
> - The Write segments should ideally be as big as the Application
>   wants to write to. (Amount of dirty pages at time of nfs-write-out
>   is a very good first approximation).
> 
> So I guess it is: I hate these patches, to much mess, too little goodness.
> 
> Thank
> Boaz
> 

Ho and one more thing.

Also Files when they will support segments and servers that request segments,
like the CEPH server, will very much enjoy the above, .i.e: Tell me the amount
you know you want to write.

And surly Objects will enjoy that tremendously. Is it a 17 bytes text file, or
the beginning of a big video file.

But the problem with Files and Objects is that they need a layout first before
they can do the right thing in .pg_test and say if this belongs to this IO or
to the next. (Files is stipe_unit maxed+aliened, Objects raid-group boundary)

So your solution is not good for files and Objects, my way solves them two.

Thanks
Boaz

  reply	other threads:[~2011-11-29 21:50 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-03  4:52 [PATCH 0/4] nfs41: allow layoutget at pnfs_do_multiple_writes Peng Tao
2011-11-29 21:34 ` Boaz Harrosh
2011-11-29 21:50   ` Boaz Harrosh [this message]
2011-11-29 21:57     ` Trond Myklebust
2011-11-29 22:40       ` Boaz Harrosh
2011-11-29 22:47         ` Trond Myklebust
2011-11-29 22:58           ` Boaz Harrosh
2011-11-29 23:30             ` Trond Myklebust
2011-11-29 23:49               ` Marc Eshel
2011-11-30  0:08                 ` Trond Myklebust
2011-11-30  0:20                   ` Marc Eshel
2011-11-30  0:37                     ` Trond Myklebust
2011-11-30  0:50                       ` Boaz Harrosh
2011-11-30 19:39                         ` J. Bruce Fields
2011-11-30  0:52                       ` Marc Eshel
2011-11-30 19:44                         ` J. Bruce Fields
2011-12-01  9:47                           ` Benny Halevy
2011-12-01 11:14                             ` J. Bruce Fields
2011-12-01 11:48                               ` J. Bruce Fields
2011-11-30  0:42                   ` Boaz Harrosh
2011-11-30  0:24               ` Boaz Harrosh
2011-11-30  0:58                 ` Trond Myklebust
2011-11-30  1:46                   ` Boaz Harrosh
2011-11-30  2:07                     ` Trond Myklebust
2011-11-30  3:08                       ` Boaz Harrosh
2011-11-30 12:33                   ` Benny Halevy
2011-11-30  0:37           ` Matt W. Benjamin
2011-11-30  0:48             ` Matt W. Benjamin
2011-11-30  1:01               ` Trond Myklebust
2011-11-30  1:03                 ` Matt W. Benjamin
2011-11-29 23:01         ` Trond Myklebust
2011-11-29 23:47           ` Boaz Harrosh
2011-11-30  3:16   ` tao.peng
2011-11-30  3:50     ` Boaz Harrosh
2011-11-30  5:05       ` tao.peng
2011-11-30 12:42         ` Benny Halevy
2011-12-03  4:52 ` [PATCH 1/4] nfsv41: export pnfs_find_alloc_layout Peng Tao
2011-12-03  4:52 ` [PATCH 2/4] nfsv41: add and export pnfs_find_get_layout_locked Peng Tao
2011-12-03  4:52 ` [PATCH 3/4] nfsv41: get lseg before issue LD IO if pgio doesn't carry lseg Peng Tao
2011-11-30 13:01   ` Benny Halevy
2011-11-30 13:20     ` Peng Tao
2011-12-03  4:52 ` [PATCH 4/4] pnfsblock: do ask for layout in pg_init Peng Tao
2011-11-29 16:40   ` Trond Myklebust
2011-11-29 17:25     ` Peng Tao
2011-11-29 17:43       ` Trond Myklebust
2011-11-30  2:55         ` tao.peng

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=4ED55399.4060707@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=bergwolf@gmail.com \
    --cc=bhalevy@tonian.com \
    --cc=linux-nfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.