Hello Anton,
we have some bad experience with consumer disks. They tend to fail quite
early and sometimes have extrem poor performance in Ceph workloads.
If possible, spend some money on reliable Samsung PM/SM863a SSDs. However a
customer of us uses the WD Blue 1TB SSDs and seems to be quite
On 26/11/2018 11.05, Yan, Zheng wrote:
> On Mon, Nov 26, 2018 at 4:30 AM Hector Martin wrote:
>>
>> On 26/11/2018 00.19, Paul Emmerich wrote:
>>> No, wait. Which system did kernel panic? Your CephFS client running rsync?
>>> In this case this would be expected behavior because rsync doesn't
>>>
Did you do any special operation (such as reset journal) before this happened
On Sat, Nov 24, 2018 at 3:58 PM 关云飞 wrote:
>
> hi,
>
>According to my understanding, the parent directory CDir fnode
> version should be incremented if creating file or directory operation
> happened. But there was
On Mon, Nov 26, 2018 at 4:30 AM Hector Martin wrote:
>
> On 26/11/2018 00.19, Paul Emmerich wrote:
> > No, wait. Which system did kernel panic? Your CephFS client running rsync?
> > In this case this would be expected behavior because rsync doesn't
> > sync on every block and you lost your file
On 26/11/2018 00.19, Paul Emmerich wrote:
> No, wait. Which system did kernel panic? Your CephFS client running rsync?
> In this case this would be expected behavior because rsync doesn't
> sync on every block and you lost your file system cache.
It was all on the same system. So is it expected
Quoting Robin H. Johnson (robb...@gentoo.org):
> On Fri, Nov 23, 2018 at 04:03:25AM +0700, Lazuardi Nasution wrote:
> > I'm looking example Ceph configuration and topology on full layer 3
> > networking deployment. Maybe all daemons can use loopback alias address in
> > this case. But how to set
Hi List,
Another interesting and unexpected thing we observed during cluster
expansion is the following. After we added extra disks to the cluster,
while "norebalance" flag was set, we put the new OSDs "IN". As soon as
we did that a couple of hundered objects would become degraded. During
that
Hi list,
During cluster expansion (adding extra disks to existing hosts) some
OSDs failed (FAILED assert(0 == "unexpected error", _txc_add_transaction
error (39) Directory not empty not handled on operation 21 (op 1,
counting from 0), full details: https://8n1.org/14078/c534). We had
On 22.11.2018 17:06, Eddy Castillon wrote:
Hello dear ceph users:
We are running a ceph cluster with Luminous (BlueStore). As you may
know this new ceph version has a new feature called "Checksums". I
would like to ask if this feature replace to deep-scrub. In our
cluster, we run
At least when I run a simple O_SYNC random 4k write test with a random
Intel 545s SSD plugged in through USB3-SATA adapter (UASP), pull USB cable
out and then recheck written data everything is good and nothing is lost
(however iops are of course low, 1100-1200)
--
With best regards,
Ok... That's better than previous thread with file download where the topic
starter suffered from normal only-metadata-journaled fs... Thanks for the link,
it would be interesting to repeat similar tests. Although I suspect it
shouldn't be that bad... at least not all desktop SSDs are that
On 25 Nov 2018, at 15.17, Vitaliy Filippov wrote:
>
> All disks (HDDs and SSDs) have cache and may lose non-transactional writes
> that are in-flight. However, any adequate disk handles fsync's (i.e SATA
> FLUSH CACHE commands). So transactional writes should never be lost, and in
> Ceph ALL
No, wait. Which system did kernel panic? Your CephFS client running rsync?
In this case this would be expected behavior because rsync doesn't
sync on every block and you lost your file system cache.
--
Paul Emmerich
Looking for help with your Ceph cluster? Contact us at https://croit.io
croit
Maybe rsync called fallocate() on the file?
Paul
--
Paul Emmerich
Looking for help with your Ceph cluster? Contact us at https://croit.io
croit GmbH
Freseniusstr. 31h
81247 München
www.croit.io
Tel: +49 89 1896585 90
Am Fr., 23. Nov. 2018 um 16:55 Uhr schrieb Hector Martin
:
>
> Background:
Ceph issues fsync's all the time
...and, of course, it has journaling :) (only fsync is of course not
sufficient)
with enterprise SSDs which have capacitors fsync just becomes a no-op and
thus transactional write performance becomes the same as non-transactional
(i.e. 10+ times faster
the real risk is the lack of power loss protection. Data can be
corrupted on unflean shutdowns
it's not! lack of "advanced power loss protection" only means lower iops
with fsync, but not the possibility of data corruption
"advanced power loss protection" is basically the synonym for
>> the real risk is the lack of power loss protection. Data can be
>> corrupted on unflean shutdowns
>
> it's not! lack of "advanced power loss protection" only means lower iops
> with fsync, but not the possibility of data corruption
>
> "advanced power loss protection" is basically the synonym
On 24 Nov 2018, at 18.09, Anton Aleksandrov wrote
We plan to have data on dedicate disk in each node and my question is
about WAL/DB for Bluestore. How bad would it be to place it on
system-consumer-SSD? How big risk is it, that everything will get
"slower than using spinning HDD for the
18 matches
Mail list logo
