From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Moving top level to a subvolume
Date: Wed, 13 Jun 2012 07:23:04 +0000 (UTC) [thread overview]
Message-ID: <pan.2012.06.13.07.23.04@cox.net> (raw)
In-Reply-To: CAG1y0sfRE502A1vEGyNUz9O9XdNZ+iu4bKs0=OKsWGtoSZKT_w@mail.gmail.com
Fajar A. Nugraha posted on Wed, 13 Jun 2012 08:49:47 +0700 as excerpted:
> As for "lose their filesystems", are there recent ones that uses one of
> the three distros above, and is purely btrfs "fault"? The ones I can
> remember (from the post to this list) were broken on earlier kernels, or
> caused by bad disks.
I tried btrfs during the 3.4 cycle for a bit, and didn't lose the whole
filesystem, but definitely found it not upto my usual standard of
robustness, my previous and back to now filesystem, Chris's former
project, reiserfs.
My system's old and has a bit of a problem with overheating in the
Phoenix summer, so has been suffering SATA resets (not the disk, the sata
chipset most likely, and/or issues with the graphics overheating since
I'm using an AMD 8xxx chipset with AGPGART split between IOMMU for
storage I/O and graphics) and full system freezes.
Not only did I have way more stuff disappearing or being zeroed out than
on reiserfs (in default data=ordered mode), but in one case I had a
segment disappear out of the middle of a file, and in another, I had
firefox's crash-resume-file /content/ show up as what SHOULD have been an
entirely unrelated configuration file.
Naturally I had backups to restore from, and if it wasn't for the
freezes, it would have likely been fine, but it's exactly this sort of
corner-case that filesystems need to be able to deal with, and what
bothered me wasn't disappearing or zeroed out last few seconds of work
with well documented explanations, but having random segments of files
that I hadn't changed (whether the app was rewriting them with the same
data's another question) in some time disappear, and having one file's
content show up with an entirely unrelated name. I thought that's the
sort of thing btrfs checksums were supposed to detect and effectively
zero out, but...
I decided that's /too/ experimental for me ATM, especially with not-quite-
stable hardware (it's worth noting that I survived bad memory and the
related crashes on reiserfs, without /that/ sort of damage, at least not
since data=ordered mode!), so am back on reiserfs for now, anyway. I'll
likely try again next year sometime...
--
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
next prev parent reply other threads:[~2012-06-13 7:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-08 19:24 Moving top level to a subvolume Matthew Hawn
2012-06-08 19:40 ` Arne Jansen
2012-06-13 7:04 ` C Anthony Risinger
2012-06-13 7:21 ` Arne Jansen
2012-06-13 9:44 ` C Anthony Risinger
2012-06-13 9:57 ` Fajar A. Nugraha
2012-06-13 16:20 ` Goffredo Baroncelli
2012-06-12 1:53 ` Duncan
2012-06-12 14:52 ` Randy Barlow
2012-06-12 15:12 ` Michael
2012-06-13 1:49 ` Fajar A. Nugraha
2012-06-13 7:23 ` Duncan [this message]
2012-06-13 9:08 ` Fajar A. Nugraha
2012-06-13 17:17 ` Duncan
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.2012.06.13.07.23.04@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).