From patchwork Tue Mar 5 12:34:41 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 10839433 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 73E711390 for ; Tue, 5 Mar 2019 12:34:46 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 61E062621E for ; Tue, 5 Mar 2019 12:34:46 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5401428B70; Tue, 5 Mar 2019 12:34:46 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F18822621E for ; Tue, 5 Mar 2019 12:34:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728187AbfCEMeo (ORCPT ); Tue, 5 Mar 2019 07:34:44 -0500 Received: from mail.kernel.org ([198.145.29.99]:50476 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726150AbfCEMeo (ORCPT ); Tue, 5 Mar 2019 07:34:44 -0500 Received: from tleilax.poochiereds.net (cpe-71-70-156-158.nc.res.rr.com [71.70.156.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2D2642087C; Tue, 5 Mar 2019 12:34:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1551789283; bh=v0lztouILTnMLpjBfQIizR7MZ4Tl8yst2w+onPeXHNs=; h=From:To:Cc:Subject:Date:From; b=qdlEprnChCsbP5XW3t334Q8xrLmBQQQ1JDJJJxOh+QxXEuA0ED8thOBZqFjtNqRlw 2hqZTift1cAWgX/2hFXYMBjGQ7n+ygTq1Ey4yQrQ51drxZkcqi3JMhurAZBpPVdJ3R gFAUb3nUU64tNK7Qwxk3YCg6U6tPQUOK0npLYtFQ= From: Jeff Layton To: zyan@redhat.com Cc: ceph-devel@vger.kernel.org, idryomov@gmail.com, sage@redhat.com Subject: [PATCH] Documentation: modern versions of ceph are not backed by btrfs Date: Tue, 5 Mar 2019 07:34:41 -0500 Message-Id: <20190305123441.22934-1-jlayton@kernel.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Sender: ceph-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Signed-off-by: Jeff Layton --- Documentation/filesystems/ceph.txt | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Documentation/filesystems/ceph.txt b/Documentation/filesystems/ceph.txt index 1177052701e1..e5b69bceb033 100644 --- a/Documentation/filesystems/ceph.txt +++ b/Documentation/filesystems/ceph.txt @@ -22,9 +22,7 @@ In contrast to cluster filesystems like GFS, OCFS2, and GPFS that rely on symmetric access by all clients to shared block devices, Ceph separates data and metadata management into independent server clusters, similar to Lustre. Unlike Lustre, however, metadata and -storage nodes run entirely as user space daemons. Storage nodes -utilize btrfs to store data objects, leveraging its advanced features -(checksumming, metadata replication, etc.). File data is striped +storage nodes run entirely as user space daemons. File data is striped across storage nodes in large chunks to distribute workload and facilitate high throughputs. When storage nodes fail, data is re-replicated in a distributed fashion by the storage nodes themselves