Messages in this thread | | | Date | Thu, 7 Aug 2008 12:23:53 -0500 | From | "Linas Vepstas" <> | Subject | Re: amd64 sata_nv (massive) memory corruption |
| |
2008/8/7 Martin K. Petersen <martin.petersen@oracle.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
| |