From: Kai Krakow <hurikhan77+btrfs@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: Clean crash...
Date: Sun, 24 Nov 2013 21:50:52 +0100 [thread overview]
Message-ID: <ce5ama-6he.ln1@hurikhan77.spdns.de> (raw)
In-Reply-To: CAK-xaQbp8Yfgpu-Tx5CV2yhACxku6_8Zv0cXFCudyFKqoq0D=w@mail.gmail.com
Hi!
Andrea Gelmini <andrea.gelmini@gmail.com> schrieb:
> and thanks a lot for your work.
> I have an USB drive with BTRFS, on which I write with different
> kernel release.
> Anyway, today I made a copy of one big file, and than powered off
> the computer with a clean shutdown (Ubuntu 13.10 - 32bit).
> Now it's impossible to me to mount it (even with kernel 3.12).
Some init systems are not clever enough to cleanly unmount filesystems under
some circumstances, you usually see a log message similar to this then:
"Unable to unmount filesystem. Shutting down anyway. Good luck"
I don't remember the exact phrasing. What it essantially means is that a
sync was issued, the init systems waits another few seconds, then shuts
down.
For your USB connected btrfs these "few seconds" could probably not be
enough. Btrfs tends to do a lot of background work from time to time which
makes it lag on unmount for a few minutes sometimes especially for USB
drives. The underlying problem could also be mounting through the device
mapper. I'm not sure how it plays into the problem but it may introduce some
sort of write behavior that btrfs is not aware of. I'm pretty sure I've read
something about device mapper and write barriers not working correctly which
are needed for btrfs being able to rely on transactions working correctly.
Either find an init system which handles this in a more sane way or simply
unmount manually before shutting the system down and wait for the unmount to
complete and return to command line (so do it from command line, not GUI).
Maybe try to avoid the device mapper.
BTW, this is only guessing. And I'm sorry it doesn't help for the particular
situation you are in currently.
Did you try to mount in recovery mode? This may, however, mount an older
version of your superblock which does not refer to your latest additions of
files on the disk but it may be newer than what you got in your backup.
HTH
Kai
next prev parent reply other threads:[~2013-11-24 20:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-21 10:06 Clean crash Andrea Gelmini
2013-11-24 20:50 ` Kai Krakow [this message]
2013-11-24 23:02 ` Clean crash... (USB memory sticks mount) Martin
2013-11-30 10:09 ` Clean crash Andrea Gelmini
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=ce5ama-6he.ln1@hurikhan77.spdns.de \
--to=hurikhan77+btrfs@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 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).