fosdem, backs and raid
Feb. 27th, 2007 09:54 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
pvaneyndLast weekend's fosdem was nice. It is always nice to meet Debian people, add to this the interesting talks and you've got a winner on your hands. I only regret I couldn't go to the social events in the evenings.
Not such a good result of fosdem was a backache that is still with me. I suspect the cramped seats in the lecture halls or some wrong move while getting into them. In any case I didn't sleep all that well Sunday->Monday, but now it is getting better.
I've been reading the fascinating results of the google/cmu disk papers, and the response from netapp on storagemojo is nice. As someone who experienced the problems of fastmail.fm's failure of multiple drives in a raid5 array it all ringed home. I'm happy fastmail decided to go to replicated raid5 arrays, but I feel we're going to go back to the filesystems of the lisp machines that included checksums on everything because the disks were not reliable enough. Hmm. ZFS already does this, not?
Death to raid 5 I would say.
Not such a good result of fosdem was a backache that is still with me. I suspect the cramped seats in the lecture halls or some wrong move while getting into them. In any case I didn't sleep all that well Sunday->Monday, but now it is getting better.
I've been reading the fascinating results of the google/cmu disk papers, and the response from netapp on storagemojo is nice. As someone who experienced the problems of fastmail.fm's failure of multiple drives in a raid5 array it all ringed home. I'm happy fastmail decided to go to replicated raid5 arrays, but I feel we're going to go back to the filesystems of the lisp machines that included checksums on everything because the disks were not reliable enough. Hmm. ZFS already does this, not?
Death to raid 5 I would say.
