I disagree with your point still - your argument was that customers don't like
to update their code so we cannot rely on them moving to better file system
code. Those same customers would be *just* as reluctant to upgrade OSD code.
Been there, done that in pure block storage, pure object storage and in file
system code (customers just don't care about the protocol, the conservative
nature is consistent).
Not a casual observation, I have been building storage systems since the
mid-80's.
Regards,
Ric
On 10/21/2015 09:22 PM, Allen Samuels wrote:
I agree. My only point was that you still have to factor this time into the argument that
by continuing to put NewStore on top of a file system you'll get to a stable system much
sooner than the longer development path of doing your own raw storage allocator. IMO,
once you factor that into 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
[email protected]
-----Original Message-----
From: Ric Wheeler [mailto:[email protected]]
Sent: Thursday, October 22, 2015 10:17 AM
To: Allen Samuels <[email protected]>; Sage Weil <[email protected]>;
[email protected]
Subject: Re: newstore direction
On 10/21/2015 08:53 PM, Allen Samuels wrote:
Fixing the bug doesn't take a long time. Getting it deployed is where the delay is. Many
companies standardize on a particular release of a particular distro. Getting them to
switch to a new release -- even a "bug fix" point release -- is a major
undertaking that often is a complete roadblock. Just my experience. YMMV.
Customers do control the pace that they upgrade their machines, but we put out
fixes on a very regular pace. A lot of customers will get fixes without having
to qualify a full new release (i.e., fixes come out between major and minor
releases are easy).
If someone is deploying a critical server for storage, then it falls back on
the storage software team to help guide them and encourage them to update when
needed (and no promises of success, but people move if the win is big. If it is
not, they can wait).
ric
________________________________
PLEASE NOTE: The information contained in this electronic mail message is
intended only for the use of the designated recipient(s) named above. If the
reader of this message is not the intended recipient, you are hereby notified
that you have received this message in error and that any review,
dissemination, distribution, or copying of this message is strictly prohibited.
If you have received this communication in error, please notify the sender by
telephone or e-mail (as shown above) immediately and destroy any and all copies
of this message in your possession (whether hard copies or electronically
stored copies).
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
