Another one bites the dust... This is Samsung 850 PRO 256GB... (6 journals on this SSDs just died...)
[root@cs23 ~]# smartctl -a /dev/sda smartctl 5.43 2012-06-30 r3573 [x86_64-linux-3.10.66-1.el6.elrepo.x86_64] (local build) Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net Vendor: /1:0:0:0 Product: User Capacity: 600,332,565,813,390,450 bytes [600 PB] Logical block size: 774843950 bytes >> Terminate command early due to bad response to IEC mode page A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options On 8 September 2015 at 18:01, Quentin Hartman <[email protected]> wrote: > On Tue, Sep 8, 2015 at 9:05 AM, Mark Nelson <[email protected]> wrote: > >> A list of hardware that is known to work well would be incredibly >>> valuable to people getting started. It doesn't have to be exhaustive, >>> nor does it have to provide all the guidance someone could want. A >>> simple "these things have worked for others" would be sufficient. If >>> nothing else, it will help people justify more expensive gear when their >>> approval people say "X seems just as good and is cheaper, why can't we >>> get that?". >>> >> >> So I have my opinions on different drives, but I think we do need to be >> really careful not to appear to endorse or pick on specific vendors. The >> more we can stick to high-level statements like: >> >> - Drives should have high write endurance >> - Drives should perform well with O_DSYNC writes >> - Drives should support power loss protection for data in motion >> >> The better I think. Once those are established, I think it's reasonable >> to point out that certain drives meet (or do not meet) those criteria and >> get feedback from the community as to whether or not vendor's marketing >> actually reflects reality. It'd also be really nice to see more >> information available like the actual hardware (capacitors, flash cells, >> etc) used in the drives. I've had to show photos of the innards of >> specific drives to vendors to get them to give me accurate information >> regarding certain drive capabilities. Having a database of such things >> available to the community would be really helpful. >> >> > That's probably a very good approach. I think it would be pretty simple to > avoid the appearance of endorsement if the data is presented correctly. > > >> >>> To that point, I think perhaps though something more important than a >>> list of known "good" hardware would be a list of known "bad" hardware, >>> >> >> I'm rather hesitant to do this unless it's been specifically confirmed by >> the vendor. It's too easy to point fingers (see the recent kernel trim bug >> situation). > > > I disagree. I think that only comes into play if you claim to know why the > hardware has problems. In this case, if you simply state "people who have > used this drive have experienced a large number of seemingly premature > failures when using them as journals" that provides sufficient warning to > users, and if the vendor wants to engage the community and potentially pin > down why and help us find a way to make the device work or confirm that > it's just not suited, then that's on them. Samsung seems to be doing > exactly that. It would be great to have them help provide that level of > detail, but again, I don't think it's necessary. We're not saying > "ceph/redhat/$whatever says this hardware sucks" we're saying "The > community has found that using this hardware with ceph has exhibited these > negative behaviors...". At that point you're just relaying experiences and > collecting them in a central location. It's up to the reader to draw > conclusions from it. > > But again, I think more important than either of these would be a > collection of use cases with actual journal write volumes that have > occurred in those use cases so that people can make more informed > purchasing decisions. The fact that my small openstack cluster created 3.6T > of writes per month on my journal drives (3 OSD each) is somewhat > mind-blowing. That's almost four times the amount of writes my best guess > estimates indicated we'd be doing. Clearly there's more going on than we > are used to paying attention to. Someone coming to ceph and seeing the cost > of DC-class SSDs versus consumer-class SSDs will almost certainly suffer > from some amount of sticker shock, and even if they don't their purchasing > approval people almost certainly will. This is especially true for people > in smaller organizations where SSDs are still somewhat exotic. And when > they come back with the "Why won't cheaper thing X be OK?" they need to > have sufficient information to answer that. Without a test environment to > generate data with, they will need to rely on the experiences of others, > and right now those experiences don't seem to be documented anywhere, and > if they are, they are not very discoverable. > > QH > > _______________________________________________ > ceph-users mailing list > [email protected] > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > -- Andrija Panić
_______________________________________________ ceph-users mailing list [email protected] http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
