From: Boaz Harrosh <boaz@plexistor.com>
To: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: Boaz Harrosh <openosd@gmail.com>, Christoph Hellwig <hch@lst.de>,
Peng Tao <bergwolf@primarydata.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 8/9] pnfs/blocklayout: return layouts on setattr
Date: Sun, 14 Sep 2014 17:28:49 +0300 [thread overview]
Message-ID: <5415A621.3020208@plexistor.com> (raw)
In-Reply-To: <CAABAsM4SxAXtBv=1XtUVyOa=jRYK9zTjYoYU9B_0ch9zmqFiaA@mail.gmail.com>
On 09/14/2014 05:16 PM, Trond Myklebust wrote:
<>
>
> There is no requirement anywhere in RFC5661 to state that a truncate
> must be prefixed by a layout return. Not in section 12 (Parallel NFS)
> nor in section 13 (NFSv4.1 as a Storage Protocol in pNFS: the File
> Layout Type), nor in the ERRATA. Existing pNFS files servers (i.e.
> NetApp) don't need it either.
>
Yes! which is why it sucks ;-)
> If a future CEPH server wants to add its own requirements, then it is
> free to issue a layoutrecall. However my understanding from
> conversations with Matt (the Ganesha release notes appear to confirm)
> was that the CRUSH algorithm is pretty much impossible to implement as
> a files layout type, so I'm confused as to why it would be a problem
> in the first place.
>
"impossible to implement" without lo-segments yes. *With* lo-segments it
is my opinion that it is possible. With the contraption of device_id per
segment.
But this argument is mute we both agree that in current code it is not
needed.
[ If at future time someone will want to implement lo-segments for
Linux files layout, I think it could be a nice optimization, just as it
is with objects and blocks.
Imagine a most simple files MDS that wants to not create filehandles(files)
on DSs that will not be reached. (Create on demand). In such case deleting
the DS-files on truncate might make sense no?
]
Xheers
Boaz
next prev parent reply other threads:[~2014-09-14 14:28 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-10 15:23 pnfs block layout driver fixes V4 Christoph Hellwig
2014-09-10 15:23 ` [PATCH 1/9] pnfs: force a layout commit when encountering busy segments during recall Christoph Hellwig
2014-09-10 15:23 ` [PATCH 2/9] pnfs: add flag to force read-modify-write in ->write_begin Christoph Hellwig
2014-09-10 15:23 ` [PATCH 3/9] pnfs: add return_range method Christoph Hellwig
2014-09-11 13:54 ` Peng Tao
2014-09-11 15:20 ` Christoph Hellwig
2014-09-11 15:30 ` Peng Tao
2014-09-11 15:36 ` Christoph Hellwig
2014-09-12 2:22 ` Peng Tao
2014-09-13 19:38 ` Christoph Hellwig
2014-09-10 15:23 ` [PATCH 4/9] pnfs/blocklayout: remove read-modify-write handling in bl_write_pagelist Christoph Hellwig
2014-09-10 15:23 ` [PATCH 5/9] pnfs/blocklayout: don't set pages uptodate Christoph Hellwig
2014-09-10 15:23 ` [PATCH 6/9] pnfs/blocklayout: rewrite extent tracking Christoph Hellwig
2014-09-11 14:11 ` Peng Tao
2014-09-11 15:21 ` Christoph Hellwig
2014-09-10 15:23 ` [PATCH 7/9] pnfs/blocklayout: implement the return_range method Christoph Hellwig
2014-09-11 14:16 ` Peng Tao
2014-09-11 15:24 ` Christoph Hellwig
2014-09-10 15:23 ` [PATCH 8/9] pnfs/blocklayout: return layouts on setattr Christoph Hellwig
2014-09-11 14:24 ` Peng Tao
2014-09-11 14:42 ` Boaz Harrosh
2014-09-11 15:25 ` Christoph Hellwig
2014-09-11 15:38 ` Trond Myklebust
2014-09-11 15:48 ` Christoph Hellwig
2014-09-11 16:14 ` Trond Myklebust
2014-09-14 10:55 ` Boaz Harrosh
2014-09-14 13:24 ` Trond Myklebust
2014-09-14 13:51 ` Boaz Harrosh
2014-09-14 14:16 ` Trond Myklebust
2014-09-14 14:28 ` Boaz Harrosh [this message]
2014-09-10 15:23 ` [PATCH 9/9] pnfs/blocklayout: allocate separate pages for the layoutcommit payload Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2014-09-09 16:40 pnfs block layout driver fixes V3 Christoph Hellwig
2014-09-09 16:40 ` [PATCH 8/9] pnfs/blocklayout: return layouts on setattr Christoph Hellwig
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=5415A621.3020208@plexistor.com \
--to=boaz@plexistor.com \
--cc=bergwolf@primarydata.com \
--cc=hch@lst.de \
--cc=linux-nfs@vger.kernel.org \
--cc=openosd@gmail.com \
--cc=trond.myklebust@primarydata.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 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.