From: Liu Bo <bo.li.liu@oracle.com>
To: "Michael Kjörling" <michael@kjorling.se>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: How does btrfs handle sudden shutdowns?
Date: Tue, 6 Nov 2012 20:54:14 +0800 [thread overview]
Message-ID: <20121106125412.GA32336@gmail.com> (raw)
In-Reply-To: <20121106123308.GA2676@yeono.kjorling.se>
On Tue, Nov 06, 2012 at 12:33:08PM +0000, Michael Kjörling wrote:
> Can btrfs deal reasonably gracefully with sudden shutdowns? (I'm
> mainly thinking of power outages which lead to logical structure
> damage but not physical media damage.)
>
AFAIK, yes, because btrfs is naturally COW supported, which means
you can roll back to the latest stable situation at least.
> What would be the risk points, file-system-wise?
>
Data loss is possible if you're not writing with O_SYNC or doing fsync
after a write.
> Can for example a rotating snapshot schedule mitigate some or all
> issues relating to sudden shutdowns, if any? (_For example_, take a
> snapshot every minute, keeping the last five; if the main file system
> fails to mount, then could the most recent usable snapshot be used as
> a fallback, or is it likely to be equally damaged or inconsistent?)
>
In your case, when we finish creating a snapshot, the whole FS is at a
stable status(both metadata and data is safely written into the disk).
So yes, you can use the latest snapshot as a fallback or backup or something.
I'd note here, btrfs somewhat suffers from ENOSPC cases, where it may
recover itself or get you into readonly state, but you data is safe at least.
thanks,
liubo
> Obviously a UPS or other form of fallback power is preferable to no
> UPS if power outages are a concern, so as to allow a controlled system
> shutdown (or fail-over to a more long-term backup power supply) in the
> event of a prolonged power outage, but I'm wondering about situations
> where such don't exist or even fail.
>
> --
> Michael Kjörling • http://michael.kjorling.se • michael@kjorling.se
> “People who think they know everything really annoy
> those of us who know we don’t.” (Bjarne Stroustrup)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-11-06 12:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-06 12:33 How does btrfs handle sudden shutdowns? Michael Kjörling
2012-11-06 12:48 ` Hugo Mills
2012-11-06 13:47 ` Michael Kjörling
2012-11-06 13:54 ` Hugo Mills
2012-11-06 12:54 ` Liu Bo [this message]
2012-11-09 1:04 ` Alex
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=20121106125412.GA32336@gmail.com \
--to=bo.li.liu@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=michael@kjorling.se \
/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).