All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shyam Prasad N <nspmangalore@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Power down tests...
Date: Fri, 4 Aug 2017 11:21:15 +0530	[thread overview]
Message-ID: <CANT5p=rND=6FZYz6+x0924JHs3G8RH+G9GXqDfoS-ndtQUXuKQ@mail.gmail.com> (raw)

Hi all,

We're running a couple of experiments on our servers with btrfs
(kernel version 4.4).
And we're running some abrupt power-off tests for a couple of scenarios:

1. We have a filesystem on top of two different btrfs filesystems
(distributed across N disks). i.e. Our filesystem lays out data and
metadata on top of these two filesystems. With the test workload, it
is going to generate a good amount of 16MB files on top of the system.
On abrupt power-off and following reboot, what is the recommended
steps to be run. We're attempting btrfs mount, which seems to fail
sometimes. If it fails, we run a fsck and then mount the btrfs. The
issue that we're facing is that a few files have been zero-sized. As a
result, there is either a data-loss, or inconsistency in the stacked
filesystem's metadata.
We're mounting the btrfs with commit period of 5s. However, I do
expect btrfs to journal the I/Os that are still dirty. Why then are we
seeing the above behaviour.

2. Another test that we're running is to create a virtual disk each on
multiple NFS mounts (softmount with timeout of 1 min), and use these
virtual disks as individual devices for one single btrfs. What is the
expected btrfs behaviour when one of the virtual disk becomes
unresponsive for a period of time (say 5 min)? Does the expectation
change if the NFS mounts are mounted with sync option?

Thanks in advance for any help you can offer.
-- 
-Shyam

             reply	other threads:[~2017-08-04  5:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-04  5:51 Shyam Prasad N [this message]
2017-08-04  6:00 ` Power down tests Adam Borowski
     [not found]   ` <CANT5p=qvu9tCf73+_PuAj9Ryy69p3JjAyHFY_pAA9eUsTz_ELA@mail.gmail.com>
2017-08-04  7:22     ` Adam Borowski
2017-08-04  7:49       ` Shyam Prasad N
     [not found]         ` <20170804145401.78e50990@job>
2017-08-04 12:09           ` Shyam Prasad N
2017-08-07  2:25             ` Chris Murphy
2017-08-07  2:15 ` Chris Murphy
2017-08-07  3:35   ` Adam Borowski
2017-08-07  6:53   ` Shyam Prasad N
2017-08-07  2:22 ` Chris Murphy
2017-08-07  7:38   ` Shyam Prasad N

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='CANT5p=rND=6FZYz6+x0924JHs3G8RH+G9GXqDfoS-ndtQUXuKQ@mail.gmail.com' \
    --to=nspmangalore@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.