linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>, Steve Dainard <sdainard@spd1.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Can't mount btrfs volume on rbd
Date: Wed, 22 Jul 2015 07:16:20 -0400	[thread overview]
Message-ID: <55AF7B84.9000009@gmail.com> (raw)
In-Reply-To: <55AEF984.9080706@cn.fujitsu.com>

[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]

On 2015-07-21 22:01, Qu Wenruo wrote:
> Steve Dainard wrote on 2015/07/21 14:07 -0700:
>> I don't know if this has any bearing on the failure case, but the
>> filesystem that I sent an image of was only ever created, subvol
>> created, and mounted/unmounted several times. There was never any data
>> written to that mount point.
>>
> Subvol creation and rw mount is enough to trigger 2~3 transaction with
> DATA written into btrfs.
> As the first rw mount will create free space cache, which is counted as
> data.
>
> But without multiple mount instants, I really can't consider another
> method to destroy btrfs so badly but with all csum OK...
>
I know that a while back RBD had some intermittent issues with data 
corruption in the default configuration when the network isn't 
absolutely 100% reliable between all nodes (which for ceph means not 
only no packet loss, but also tight time synchronization between nodes 
and only very low network latency).

I also heard somewhere (can't remember exactly where though) of people 
having issues with ZFS on top of RBD.

The other thing to keep in mind is that Ceph does automatic background 
data scrubbing (including rewriting stuff it thinks is corrupted), so 
there is no guarantee that the data on the block device won't change 
suddenly without the FS on it doing anything.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  reply	other threads:[~2015-07-22 11:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-11 15:26 Can't mount btrfs volume on rbd Steve Dainard
2015-06-12  7:23 ` Qu Wenruo
2015-06-12 16:09   ` Steve Dainard
2015-06-15  8:06     ` Qu Wenruo
2015-06-15 16:19       ` Steve Dainard
2015-06-16  1:27         ` Qu Wenruo
2015-07-13 20:22           ` Steve Dainard
2015-07-14  1:22             ` Qu Wenruo
2015-07-21  8:38               ` Qu Wenruo
2015-07-21 11:15                 ` Austin S Hemmelgarn
2015-07-21 21:07                   ` Steve Dainard
2015-07-22  2:01                     ` Qu Wenruo
2015-07-22 11:16                       ` Austin S Hemmelgarn [this message]
2015-07-22 14:13                         ` Gregory Farnum
2015-07-23 11:11                           ` Austin S Hemmelgarn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55AF7B84.9000009@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo@cn.fujitsu.com \
    --cc=sdainard@spd1.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).