On Wed, Mar 12, 2014 at 12:28:16AM -0500, Alex Elder wrote:
> On 03/11/2014 11:24 PM, Guangliang Zhao wrote:
Hi Alex,
Thanks very much for the reviews, version 2 would coming soon.
> > Hi,
> >
> > I am sorry that didn't notice Jean-Tiare's mail at all, just sage's
> > reminds me.
> >
> > Ther
I am sure all of that will work, but it doesn't explain why these
properties must be stored and named separately to crush rulesets. To
flesh this out one also needs "get" and "list" operations for the sets
of properties, which feels like overkill if there is an existing place
we could be storing t
Hi,
I must admit I've put it aside for the moment. So, I really don't mind,
on the contrary, if you implement the DISCARD op.
On 03/12/2014 05:24 AM, Guangliang Zhao wrote:
I am sorry that didn't notice Jean-Tiare's mail at all, just sage's
reminds me.
--
Jean-Tiare, shared-hosting team
--
On 12/03/2014 13:39, John Spray wrote:
> I am sure all of that will work, but it doesn't explain why these
> properties must be stored and named separately to crush rulesets. To
> flesh this out one also needs "get" and "list" operations for the sets
> of properties, which feels like overkill if t
OK, in chatting about this I've been convinced that it's legitimately
separate, because the CRUSH ruleset is mutable during the lifetime of
a pool but the EC settings are not. I suppose the way we could
explain the logical separation for users is to say that the CRUSH
ruleset is mainly about locat
On 12/03/2014 15:35, John Spray wrote:
> OK, in chatting about this I've been convinced that it's legitimately
> separate, because the CRUSH ruleset is mutable during the lifetime of
> a pool but the EC settings are not. I suppose the way we could
> explain the logical separation for users is to
On Wed, 12 Mar 2014, John Spray wrote:
> I am sure all of that will work, but it doesn't explain why these
> properties must be stored and named separately to crush rulesets. To
> flesh this out one also needs "get" and "list" operations for the sets
> of properties, which feels like overkill if t
On Wed, 12 Mar 2014, John Spray wrote:
> OK, in chatting about this I've been convinced that it's legitimately
> separate, because the CRUSH ruleset is mutable during the lifetime of
> a pool but the EC settings are not. I suppose the way we could
> explain the logical separation for users is to s
Hi ceph-devel,
I have been playing with the new erasure code functionality and I have
noticed that the erasure coded PG remains in "peering" state forever. Is
that normal?
I have a scenario with four servers each with two OSDs (total of eight
OSDs). Then I define the extra crush rule to get four
ramu eppa gmail.com> writes:
>
> Hi Wiessner,
>
>Actually I created zpool and this is mounted to /dev/sdb and then set a
> mountpint to osd.The space showing is 144GB.But the osd's are going down
after
> rbd image is while running.
>
> Thanks,
> Ramu.
>
> --
> To unsubscribe from this l
Hi
On 12/03/2014 18:40, Lluís Pàmies i Juárez wrote:
> Hi ceph-devel,
>
> I have been playing with the new erasure code functionality and I have
> noticed that the erasure coded PG remains in "peering" state forever. Is
> that normal?
>
> I have a scenario with four servers each with two OSDs (t
The 'man 2 open' states
---snip---
The behaviour of O_DIRECT with NFS will differ from local file systems. (...)
The NFS protocol does not support passing the flag to the server,
so O_DIRECT I/O will bypass the page cache only on the client;
the server may still cache the I/O.
---snip---
Q1:
Kasper,
I only know about the kernel cephfs... but there are special code
paths for O_DIRECT read/writes. Both read and write bypass the page
cache and send commands directly to OSDs for the objects, on the write
case the object has a write lock with MDS. So unlike NFS this seams
like it does the
Glad to hear it's working for you now ;-)
There are important bug fixes daily: it is worth getting the latest Firefly
from https://github.com/ceph/ceph/tree/firefly
If you run into a problem again, it would be great if you could preserve the
environment in which it happens and post a bug report
Hi Kasper,
In order to do what you want here, we need to make O_DIRECT-initiated
requests on the client get a flag that tells the OSD to also bypass its
cache. That doesn't happen right now.
Assuming we do add that flag, we can either make the IO actually do
O_DIRECT, or we can make it do som
It could only handle the read and write operations now,
extend it for the coming discard support.
Signed-off-by: Guangliang Zhao
---
drivers/block/rbd.c | 96 +--
1 file changed, 63 insertions(+), 33 deletions(-)
diff --git a/drivers/block/rbd.c
It need to copyup the parent's content when layered writing,
but an entire object write would overwrite it, so skip it.
Signed-off-by: Guangliang Zhao
---
drivers/block/rbd.c | 49 ++---
1 file changed, 34 insertions(+), 15 deletions(-)
diff --git a
This patch add the discard support for rbd driver.
There are there types operation in the driver:
1. The objects would be removed if they completely contained
within the discard range.
2. The objects would be truncated if they partly contained within
the discard range, and align with their b
On 03/12/2014 10:21 PM, Guangliang Zhao wrote:
> It need to copyup the parent's content when layered writing,
> but an entire object write would overwrite it, so skip it.
>
> Signed-off-by: Guangliang Zhao
> ---
> drivers/block/rbd.c | 49 ++---
> 1
On 03/12/2014 10:21 PM, Guangliang Zhao wrote:
> It could only handle the read and write operations now,
> extend it for the coming discard support.
Wow, it looks like you took all of my suggestions.
This looks good.
Reviewed-by: Alex Elder
> Signed-off-by: Guangliang Zhao
> ---
> drivers/bl
On 03/12/2014 10:21 PM, Guangliang Zhao wrote:
> This patch add the discard support for rbd driver.
>
> There are there types operation in the driver:
> 1. The objects would be removed if they completely contained
>within the discard range.
> 2. The objects would be truncated if they partly co
On Wed, Mar 12, 2014 at 11:47:36PM -0500, Alex Elder wrote:
> On 03/12/2014 10:21 PM, Guangliang Zhao wrote:
> > It could only handle the read and write operations now,
> > extend it for the coming discard support.
>
> Wow, it looks like you took all of my suggestions.
>
> This looks good.
Good
22 matches
Mail list logo
