linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Kirby <sim@hostway.ca>
To: linux-btrfs@vger.kernel.org
Subject: btrfsck failures on old backup volumes
Date: Wed, 16 May 2012 17:57:37 -0700	[thread overview]
Message-ID: <20120517005737.GC12958@hostway.ca> (raw)

Hi!

We have some btrfs rsync-snapshot backup servers which have been running
since about mid-2009, with a pretty good record so far. We've been
following the development kernels and hitting some bugs here an there,
but we still haven't managed to lose anything yet. The main problems we
have ran in to relate to ENOSPC and reporting full when "df" only shows
74% used, etc.

Recently, with some newer kernels (currently 3.4-rc6), we have some cases
where we can no longer write to some volumes -- they report out of space
even when trying to rm, or hang forever. Most volumes are 3TB carved from
some LVM'd attached storage.

Since btrfsck seems to exist now in git btrfs-progs, and this data is
already elsewhere, I figured it'd be worthwhile to try. On this one FS,
btrfsck in check mode reported thousands of errors. The --repair mode
did as well, and then exited with "failed to repair damaged filesystem,
aborting". Output logs (huge) are here: http://0x.ca/sim/ref/3.4-rc6/

I'm not sure how long these consistency issues have been on disk, since
these file systems have been around for many years. Is this useful data?
Would it be useful to try to reproduce these issues on smaller devices,
or are the current results helpful in any way for improving btrfsck?

Mount options for these are "noacl,noatime,nodiratime,compress-force",
and they were mkfs'd with no special options.

Cheers,

Simon-

                 reply	other threads:[~2012-05-17  0:57 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20120517005737.GC12958@hostway.ca \
    --to=sim@hostway.ca \
    --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).