linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).