linux-kernel - Re: amd64 sata_nv (massive) memory corruption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3ae3aa420808071023i5263600bo8b8627194941d8f3@mail.gmail.com>
Date:	Thu, 7 Aug 2008 12:23:53 -0500
From:	"Linas Vepstas" <linasvepstas@...il.com>
To:	"Martin K. Petersen" <martin.petersen@...cle.com>
Cc:	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	"John Stoffel" <john@...ffel.org>,
	"Alistair John Strachan" <alistair@...zero.co.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: amd64 sata_nv (massive) memory corruption

2008/8/7 Martin K. Petersen <martin.petersen@...cle.com>:

> Linas> Thus, a "tactical" solution seems to be pure-software
> Linas> check-summing in a kernel device-mapper module, performance be
> Linas> damned.
>
> What I don't understand is why you are so focused on fixing this at
> the RAID level.  I think your time would be better spent contributing
> to btrfs which gives you checksums and redundancy on consumer grade
> hardware today.  It's is only a few months away from GA.  So why not
> implement scrubbing in btrfs instead of spending time on a kludgy
> device mapper module with crappy performance?

Let me count the ways:
-- Time is an important consideration; I'd do this at home,
   spare-time, sandwiched between my formal commitments.
-- The device mapper interfaces are modular enough, and
   there are enough other device-mapper modules to serve
   as example code, that I could probably knock off the basic
    function in less  than a week, and then spend a few months
   polishing and enhancing at leisure.
-- Learning the in's and out's of btrfs would take more than
   a week.
-- Timeliness, modularity -- suppose I am pressed for time,
   and it takes me 6 months to develop a dm  module. I am
   pretty sure that the api's won't change out from under me,
   an my patches will still apply. By contrast, btrfs will likely
   undergo major changes by then, so slow-moving patches
   would likely be rotten/superceeded by then.
-- I'm architecturally conservative. Looking at the btrfs page
   does not make me comfortable: it seems to have a do-it-all
   set of goals. When I was younger, I created some do-it-all
   projects, and found that 1) the community was never as
   excited as I was, and 2) the list of desired features was
   overwhelmingly large, which means most didn't get done,
   and most of the rest were little more than proof-of-concept.
   My gut-sense, irrational vibe from the btrfs page is that its
   over-reaching -- examples of over-reaching projects that
   got in trouble were evms and reiserfs -- and so wait-n-see
   is my prudent response.
-- By contrast, raid+lvm already does most of what I need;
    I'd be happier seeing a project that leverages the existing
    raid+lvm infrastructure than one that fundamentally
    rethinks/redesigns everything. Nothing wrong with
    fundamental architectural re-thinks; its just that they're
    much riskier.

I dunno, I'm not even sure I have the time to do a dm module
I'm still tossing around the idea.

--linas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/