linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tracy Reed <treed@ultraviolet.org>
To: Clemens Eisserer <linuxhippy@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: slow deletion of files
Date: Mon, 12 Jul 2010 14:33:02 -0700	[thread overview]
Message-ID: <20100712213302.GH2244@tracyreed.org> (raw)
In-Reply-To: <AANLkTim2GsB-1BKaDUDbvzWkvNRi3YKe7c2iiGm6nRS9@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

On Mon, Jul 12, 2010 at 10:30:20PM +0200, Clemens Eisserer spake thusly:
> Another reason I moved away was btrfs corrupted, and btrfsck is still
> not able to repair it.
> I really like btrfs but in my opinion it has still a long road to go
> and declaring it stable in 2.6.35 is quite optimistic at best.

How many of reiserfs' problems were due to bugs in reiserfs vs due to
buggy PC memory which is rarely ECC? These fancy new filesystems hold
a lot of datastructures in memory compared to older filesystems which
would seem to increase the chances that they could be broken by bad
RAM. I am concerned that a flipped bit in memory somewhere could be
written out to disk and hose the filesystem. I know ZFS implements a
lot of checksums to prevent this sort of thing but it also tends to
run on nicer hardware with ECC. I never had corruption problems with
reiserfs even while running it on many terabytes of disk. I know
plenty of people who constantly lost data to it. I can't explain the
difference other than hardware.

-- 
Tracy Reed
http://tracyreed.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2010-07-12 21:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-11 14:59 slow deletion of files Lubos Kolouch
2010-07-11 20:20 ` Konstantinos Skarlatos
2010-07-12 20:30   ` Clemens Eisserer
2010-07-12 20:32     ` Clemens Eisserer
2010-07-12 21:33     ` Tracy Reed [this message]
2010-07-13  9:29     ` Sander
2010-07-13  1:12 ` Chris Mason

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=20100712213302.GH2244@tracyreed.org \
    --to=treed@ultraviolet.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linuxhippy@gmail.com \
    /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).