linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Error from Trying to Mount Btrfs
Date: Wed, 13 Nov 2013 12:52:56 +0000 (UTC)	[thread overview]
Message-ID: <pan$63fda$df85d33$eff0354a$38afd821@cox.net> (raw)
In-Reply-To: 1382915825.53433.YahooMailNeo@web125705.mail.ne1.yahoo.com

gatlin sullivan posted on Sun, 27 Oct 2013 16:17:05 -0700 as excerpted:

> I have the attached error from trying to mount btrfs on external hard
> drive. The F.S. was my primary system, then I dd'd it to an external and
> reinstalled Fedora.
> 
> 
> I tried to follow
> https://btrfs.wiki.kernel.org/index.php/
Problem_FAQ#Filesystem_can.27t_be_mounted_by_label.
> I used "# btrfs device scan --all-devices" before attempting to mount.
> 
> 
> What should I do?
> 
> Appreciatively, Gatlin.
> 
> P.S.
> This file system is very important to me becasue it has a large
> collection of songs.

Commenting on that P.S.:

Of course if you've read the wiki you know this, but it's worth repeating 
for others who may come across this in their googles, etc...

As noted both on the wiki and in description for the kernel's btrfs 
option itself, btrfs remains classified as an experimental filesystem, 
suitable only for testing with data that you don't care about losing, 
either because it's well backed up to tested usable backups (preferably 
on something more stable than btrfs), or because it's low-value data you 
don't particularly care about losing if the test goes wrong and btrfs 
eats your data for breakfast in the first place.

IOW, importance is relative, and relative to the value of the time it 
would have taken to research the filesystem and ensure backups 
appropriate to the importance of the data, if you didn't do that research 
and have those backups, by definition your time saved in skipping that 
was more important to you than the potential loss of that data on what 
you would have known if you /really/ cared about the data you put on it, 
was an experimental filesystem unfit to the purpose you evidently used it 
for.

So you saved the time on the research and backups because you considered 
that more important than the data, and are now paying the tradeoff cost 
for that time saved with the potential loss of the obviously relatively 
unimportant data.  No big deal, since self-evidently that time was more 
important to you than the data you were risking by not spending it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


      parent reply	other threads:[~2013-11-13 12:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-27 23:17 Error from Trying to Mount Btrfs gatlin sullivan
2013-11-13  8:27 ` Kai Krakow
2013-11-13 12:52 ` Duncan [this message]

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='pan$63fda$df85d33$eff0354a$38afd821@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --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).