linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomasz Kusmierz <tom.kusmierz@gmail.com>
To: Roman Mamedov <rm@romanrm.ru>
Cc: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>,
	Chris Mason <chris.mason@fusionio.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs for files > 10GB = random spontaneous CRC failure.
Date: Tue, 05 Feb 2013 14:18:40 +0000	[thread overview]
Message-ID: <511114C0.8060008@gmail.com> (raw)
In-Reply-To: <20130205194623.07a9bcfd@natsu>

On 05/02/13 13:46, Roman Mamedov wrote:
> On Tue, 05 Feb 2013 10:16:34 +0000
> Tomasz Kusmierz <tom.kusmierz@gmail.com> wrote:
>
>> that I was using one of those fantastic pci 4 port ethernet cards and
>> printer was directly to it - after moving it and everything else to
>> switch all problem and issues have went away. AT the moment I'm running
>> server for 2 weeks without any corruptions, any random kernel btrfs
>> crashes etc.
> If moving the printer over to a switch helped, perhaps it is indeed an
> electrical interference problem, but if your card is an old one from Sun, keep
> in mind that they also have some problems with DMA on machines with large
> amounts of RAM:
>
>    "sunhme" experiences corrupt packets if machine has more than 2GB of memory
>    https://bugzilla.kernel.org/show_bug.cgi?id=10790
>
> Not hard to envision a horror story scenario where a rogue network card would
> shred your filesystem buffer cache with network packets DMAed all over it,
> like bullets from a machine gun :) But in reality afaik IOMMU is supposed to
> protect against this.
>
As I said in reply to Chris it was definitely and electrical issue. Back 
in the days when cat5 eth was a novelty I've learnt hard way a simple 
lesson - don't be skimp, always separate with switch. I've learnt it on 
networks where parties were not necessary powered from same circuit or 
even supply phase. Since this setup is limited to my home I've violated 
my own old rule - and it back fired on me.

Anyway thanks for info on "sunhme" - WOW ....

  reply	other threads:[~2013-02-05 14:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-14 11:09 btrfs for files > 10GB = random spontaneous CRC failure Tomasz Kusmierz
2013-01-14 14:59 ` Chris Mason
2013-01-14 15:22   ` Tomasz Kusmierz
2013-01-14 15:57     ` Chris Mason
2013-01-14 16:32       ` Tomasz Kusmierz
2013-01-14 16:34         ` Chris Mason
2013-01-15 16:54           ` Lars Weber
2013-01-15 23:32           ` Tom Kusmierz
2013-01-15 23:44             ` Chris Mason
2013-01-16  9:21             ` Bernd Schubert
2013-02-05 10:16               ` Tomasz Kusmierz
2013-02-05 12:49                 ` Chris Mason
2013-02-05 14:10                   ` Tomasz Kusmierz
2013-02-05 13:46                 ` Roman Mamedov
2013-02-05 14:18                   ` Tomasz Kusmierz [this message]
2013-01-14 16:20     ` Roman Mamedov
2013-01-14 16:34       ` Tomasz Kusmierz
  -- strict thread matches above, loose matches on Subject: below --
2013-01-14 11:17 Tomasz Kusmierz
2013-01-14 11:25 ` Roman Mamedov
2013-01-14 11:43   ` Tomasz Kusmierz

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=511114C0.8060008@gmail.com \
    --to=tom.kusmierz@gmail.com \
    --cc=bernd.schubert@itwm.fraunhofer.de \
    --cc=chris.mason@fusionio.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=rm@romanrm.ru \
    /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).