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