[lkml]   [2008]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: amd64 sata_nv (massive) memory corruption
2008/8/7 Martin K. Petersen <>:

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


 \ /
  Last update: 2008-08-07 19:27    [W:0.090 / U:3.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site