linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Berend Dekens <btrfs@cyberwizzard.nl>
To: linux-btrfs@vger.kernel.org
Subject: BTRFS and power loss ~= corruption?
Date: Wed, 24 Aug 2011 15:11:32 +0200	[thread overview]
Message-ID: <4E54F884.9090004@cyberwizzard.nl> (raw)

Hi,

I have followed the progress made in the btrfs filesystem over time and 
while I have experimented with it a little in a VM, I have not yet used 
it in a production machine.

While the lack of a complete fsck was a major issue (I read the update 
that the first working version is about to be released) I am still 
worried about an issue I see popping up.

How is it possible that a copy-on-write filesystem becomes corrupted if 
a power failure occurs? I assume this means that even (hard) resetting a 
computer can result in a corrupt filesystem.

I thought the idea of COW was that whatever happens, you can always 
mount in a semi-consistent state?

As far as I can see, you wind up with this:
- No outstanding writes when power down
- File write complete, tree structure is updated. Since everything is 
hashed and duplicated, unless the update propagates to the highest 
level, the write will simply disappear upon failure. While this might be 
rectified with a fsck, there should be no problems mounting the 
filesystem (read-only if need be)
- Writes are not completed on all disks/partitions at the same time. The 
checksums will detect these errors and once again, the write disappears 
unless it is salvaged by a fsck.

Am I missing something? How come there seem to be plenty people with a 
corrupt btrfs after a power failure? And why haven't I experienced 
similar issues where a filesystem becomes unmountable with say NTFS or 
Ext3/4?

-- 
Regards,
Berend Dekens


             reply	other threads:[~2011-08-24 13:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-24 13:11 Berend Dekens [this message]
2011-08-24 13:31 ` BTRFS and power loss ~= corruption? Arne Jansen
2011-08-24 15:01   ` Berend Dekens
2011-08-24 15:04     ` *** GMX Spamverdacht *** " Arne Jansen
2011-08-24 15:13       ` Berend Dekens
2011-08-24 17:06         ` Mitch Harder
2011-08-24 21:00           ` Ahmed Kamal
2011-08-25  3:31           ` Anand Jain
2011-08-25 17:55             ` Martin Steigerwald
2011-08-25 22:16               ` Maciej Marcin Piechotka
2011-11-09 20:15                 ` Martin Steigerwald
2011-08-25 23:01 ` Gregory Maxwell
2011-08-26  6:37   ` Arne Jansen
2011-08-26  7:48     ` Mike Fleetwood
2011-08-26  9:30       ` Arne Jansen
2011-11-09 17:33   ` Stefan Behrens

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=4E54F884.9090004@cyberwizzard.nl \
    --to=btrfs@cyberwizzard.nl \
    --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 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).