An article so stupid it’s funny.
I love the quote, “The statistic probability of this event is itself statistically undefined.”
He also has a follow-up article. Not quite as stupid, but still has some gems: “the coincidence of the two main firms that control the world having a perfect track record is impossible2.”
Terry Duffy’s testimony about the May 6 debacle.
So that’s why it’s so much better to trade futures than stocks.
On the initial kernel I used for install, I couldn’t do a rebalance of the data (kernel oops)…
A new kernel wouldn’t boot claiming fsck errors. Turned out to be a malformed udevadm install.
And to top it off, X stopped working.
I reformatted as ext3, fixed the udevadm, and reinstalled the mesa, drm, and X packages, and all works fine.
I’m not sure if the second and third problems had anything to do with btrfs, and I’ve seen no other signs of corruption. But given that I’m always running bleeding edge kernels, even the oops is disheartening.
Seems like a good idea, but I’ll wait before putting it on my root again (or on my NAS)…
“Feel, feel, I say—feel for all you’re worth, and even if it half kills you, for that is the only way to live, especially to live at this terrible pressure, and the only way to honour and celebrate these admirable beings who are our pride and inspiration.”
My desktop now has btrfs as a root filesystem. I largely followed this guide. I used a lucid (daily build) live cd to get the job done. I didn’t reinstall, so I had to resize partitions to get a separate /boot (parted doesn’t do this anymore, but gparted does). My kernel is a custom kernel with btrfs as a module, so that was good. But the update-initramfs doesn’t remake initrds for kernels not installed via package (ya ya, I should use a package), so one has to do that specially. Also, the root device as specified in grub’s config needs to change for the new UUID. With those caveats, the guide worked perfectly.
Here are the bonnie numbers:
btrfs
Sequential Output (Char) 238
Sequential Output (Block) 48884
Sequential Output (Rewrite) 31956
Sequential Input (Char) 4596
Sequential Input (Block) 89337
Random Seeks 114
Again, the sequential output may or may not make sense, but it is consistent with the previous number. The sequential input number is way too high, as my disk shouldn’t be able of reading more than 75MB/sec (so says hdparm). I’m starting to lose faith in bonnie…
I tried to rebalance, but I got an oops… So that’s not working for now.
I’ll play with this for a while before I consider putting it on my NAS. :)
Thinking about taking the leap to btrfs… Here are some bonnie++ numbers for ext3 & btrfs filesystems mounted via loopback, as well as the raw underlying filesystem (ext3):
ext3 btrfs raw
Sequential Output (Char) 491 309 790
Sequential Output (Block) 78512 50047 58462
Sequential Output (Rewrite) 28843 32065 31820
Sequential Input (Char) 2200 3887 2725
Sequential Input (Block) 70306 79169 78204
Random Seeks 156 114 175
Nothing too interesting, but it looks like sequential input performed well. Sequential output didn’t (but the ext3/loopback did much better than ext3/raw, so maybe it’s just noise?).