I suspect could be punted to a subsequent
release (i.e., I'm out of large blocks, but there's plenty of fragmented
available space -- This can happen, but's a pretty pathological case which
becomes rare-er and rare-er as you scale-out)
Allen Samuels
Software Architect, Emerging
rebuild.
The average case would be 1.5x and this is inverse with the MTTDL, i.e., this
behavior cuts the MTTDL in half.
Allen Samuels
Software Architect, Fellow, Systems and Software Solutions
2880 Junction Avenue, San Jose, CA 95134
T: +1 408 801 7030| M: +1 408 780 6416
allen.samu
I have a question about rebuild in the following situation:
I have a pool with 3x replication.
For one particular PG we'll designate the active OSD set as [1,2,3] with 1 as
the primary.
Assume 2 and 3 crash with a TOTAL loss of local data.
2 restarts, fiddles about and then start the backfill pro
How would this kind of split affect small transactions? Will each split be
separately transactionally consistent or is there some kind of meta-transaction
that synchronizes each of the splits?
Allen Samuels
Software Architect, Fellow, Systems and Software Solutions
2880 Junction Avenue, San
trend toward thread-per-core software development will also tend
to support the "do it in user-space" trend. That's because most of the kernel
and file-system interface is architected around the blocking "thread-per-IOP"
model and is unlikely to change in the future.
I am pushing internally to open-source ZetaScale. Recent events may or may not
affect that trajectory -- stay tuned.
Allen Samuels
Software Architect, Fellow, Systems and Software Solutions
2880 Junction Avenue, San Jose, CA 95134
T: +1 408 801 7030| M: +1 408 780 6416
allen.samu
o the equation the "on
top of an FS" path doesn't look like such a clear winner.
Allen Samuels
Software Architect, Fellow, Systems and Software Solutions
2880 Junction Avenue, San Jose, CA 95134
T: +1 408 801 7030| M: +1 408 780 6416
allen.samu...@sandisk.com
-Original Me
IOPS
OR huge amounts of DRAM. Regardless of the choice, you'll see a significant
degradation of performance while the scrub is ongoing -- which is one of the
biggest problems with clustered systems (expensive and extensive maintenance
operations).
Allen Samuels
Software Architect
plete roadblock. Just my experience.
YMMV.
Allen Samuels
Software Architect, Fellow, Systems and Software Solutions
2880 Junction Avenue, San Jose, CA 95134
T: +1 408 801 7030| M: +1 408 780 6416
allen.samu...@sandisk.com
-Original Message-
From: Ric Wheeler [mailto:rwhee...@re
y
decreases.
You can't avoid (2) as long as you're using a file system.
Yes an LSM tree performs better on HDD than does a B-tree, which is a good
argument for keeping the KV module pluggable.
Allen Samuels
Software Architect, Fellow, Systems and Software Solutions
2880 Junction A
retty much required for deep scrubbing.
Allen Samuels
Software Architect, Fellow, Systems and Software Solutions
2880 Junction Avenue, San Jose, CA 95134
T: +1 408 801 7030| M: +1 408 780 6416
allen.samu...@sandisk.com
-Original Message-
From: ceph-devel-ow...@vger.kernel.org
[mailto:cep
Yes, I'm referring to the C++ vtable.
Allen Samuels
Software Architect, Emerging Storage Solutions
2880 Junction Avenue, Milpitas, CA 95134
T: +1 408 801 7030| M: +1 408 780 6416
allen.samu...@sandisk.com
-Original Message-
From: James (Fei) Liu-SSI [mailto:james@ssi.samsun
h the vtbl which is loaded from a
known constant offset in the object).
Allen Samuels
Chief Software Architect, Emerging Storage Solutions
951 SanDisk Drive, Milpitas, CA 95035
T: +1 408 801 7030| M: +1 408 780 6416
allen.samu...@sandisk.com
-Original Message-
From: cep
I was referring strictly to compression. Dedupe is a whole 'nother issue.
I agree that dedupe on a per-OSD basis isn't interesting. It needs to be done
at the pool level (or higher).
Allen Samuels
Software Architect, Systems and Software Solutions
2880 Junction Avenue, San Jose,
and chunksize. That would also
provide backward compatibility and allow per-object compression diversity.
Then you'd want to add verbiage to the individual access schemes to
allow/disallow compression. For file systems you'd want that on a per-directory
basis or perhaps even better a set o
/jemalloc -- oops it uses more memory discussion will go away.
Allen Samuels
Software Architect, Systems and Software Solutions
2880 Junction Avenue, San Jose, CA 95134
T: +1 408 801 7030| M: +1 408 780 6416
allen.samu...@sandisk.com
-Original Message-
From: ceph-devel-ow...@vger.ker
u get high counts of small objects. I agree
that paying $ for RAM that translates into actual performance isn't really a
problem. It really boils down to your workload and access pattern.
Allen Samuels
Software Architect, Systems and Software Solutions
2880 Junction Avenue, San Jose, CA 9
Don't we need to double-index the data structure?
We need it indexed by atime for the purposes of eviction, but we need it
indexed by object name for the purposes of updating the list upon a usage.
Allen Samuels
Software Architect, Systems and Software Solutions
2880 Junction Avenue
ely to be used is flushed to storage with some mechanism that allows
batched updates.
Allen Samuels
Software Architect, Systems and Software Solutions
2880 Junction Avenue, San Jose, CA 95134
T: +1 408 801 7030| M: +1 408 780 6416
allen.samu...@sandisk.com
-Original Message-
From: ceph-de
This seems much better than the current mechanism. Do you have an estimate of
the memory consumption of the two lists? (In terms of bytes/object?)
Allen Samuels
Software Architect, Systems and Software Solutions
2880 Junction Avenue, San Jose, CA 95134
T: +1 408 801 7030| M: +1 408 780 6416
ince small objects are replicated
rather than ECed). This will have a massive impact on backend storage I/O as
the basic data/metadata ratio is complete skewed (both for static storage and
dynamic I/O count).
Allen Samuels
Software Architect, Emerging Storage Solutions
2880 Junction Avenue, Mi
This covers the read and write, what about the delete? One of the major issues
with Dedupe, whether global or local is to address the inherent ref-counting
associated with sharing of pieces of storage.
Allen Samuels
Software Architect, Emerging Storage Solutions
2880 Junction Avenue, Milpitas
> -Original Message-
> From: Gregory Farnum [mailto:g...@gregs42.com]
> Sent: Wednesday, June 10, 2015 12:17 PM
> To: Shishir Gowda
> Cc: ceph-devel@vger.kernel.org
> Subject: Re: Ceph tier’ing enhancements blue print for jewel
>
> On Tue, Jun 9, 2015 at 7:52 PM, Shishir Gowda
> wrote:
>
good thing.
Allen Samuels
Chief Software Architect, Emerging Storage Solutions
951 SanDisk Drive, Milpitas, CA 95035
T: +1 408 801 7030| M: +1 408 780 6416
allen.samu...@sandisk.com
-Original Message-
From: ceph-devel-ow...@vger.kernel.org
[mailto:ceph-devel-ow...@vger.kernel.org] On
Another thing we're looking into is compression. The intersection of
compression and object striping (fracturing) is interesting. Is the striping
variable on a per-object basis?
Allen Samuels
Chief Software Architect, Emerging Storage Solutions
951 SanDisk Drive, Milpitas, CA 95035
T: +
You talk about restting the object map on a restart after a crash -- I assume
you mean rebuilding, how long will this take?
---
The true mystery of the world is the visible, not the invisible.
Oscar Wilde (1854 - 1900)
Allen Samuels
move.
---
Now I know what a statesman is; he's a dead politician. We need more statesmen.
Bob Edwards
Allen Samuels
Chief Software Architect, Emerging Storage Solutions
951 SanDisk Drive, Milpitas, CA 95035
T: +1 408 801 7030| M: +1 408 780 6416
allen.samu...@sandisk.com
---
a simpler
implementation task.
---
Never put off until tomorrow what you can do the day after tomorrow.
Mark Twain
Allen Samuels
Chief Software Architect, Emerging Storage Solutions
951 SanDisk Drive, Milpitas, CA 95035
T: +1 408 801 7030| M: +1 40
28 matches
Mail list logo
