1,021 reputation
1722
bio website
location
age
visits member for 4 years, 9 months
seen Dec 9 at 19:09

Nov
20
awarded  Caucus
Nov
4
awarded  Popular Question
Oct
26
comment limit linux background flush (dirty pages)
Wow, thanks for your input. Although this wasn't the case for me, you give me yet another reason to avoid HW RAID altogether and move on to HBA only setups. HW RAID still has the BBWC advantage, but with things like bcache moving into the kernel, even that vanishes. The con side for HW RAID is exactly the kind of firmware bugs you describe. I did have another system with DRBD setup and high I/O load causing firmware-resets, so this is not rare to come across (might have been exactly that bug).
Sep
4
awarded  Notable Question
Aug
4
awarded  Nice Answer
Jul
2
awarded  Curious
Mar
25
awarded  Yearling
Feb
6
answered OpenVPN clients traffic
Jan
9
awarded  Nice Answer
Dec
2
awarded  Famous Question
Sep
24
awarded  Popular Question
Jun
15
comment Is KVM stable enough for production use in 2011?
@JoelESalas: Live migration is possible with dual primary mode, but I do not use that. I assume DRBD protocol C is mandatory in that scenario. DRBD behaves much like shared storage in dual primary. I have LVM below DRBD and create one DRBD pair per VM disk. With LVM on top, use LVM cluster support.
Jun
11
comment Is KVM stable enough for production use in 2011?
@JoelESalas: I currently prefer DRBD below the VMs and cache=none. cache=writethrough was bad advice actually, and it is not default anymore. cache=writeback is OK for low IO machines, but heavy writers gain problems with it, so cache=none is best option now.
May
15
comment KVM guest io is much slower than host io: is that normal?
cache=writeback does not add any real-life risks (important data is not in danger, only in-flight data, which is discarded on crash anyways). Only cache=unsafe does. Writeback does not imply additional hardware requirements ("battery backed RAID array" does not help in any way). It has the same integrity level as an HDD write-cache: both are flushed when necessary by the operating system.
Apr
23
comment What are the risks of running a database on a server without ECC RAM?
For MySQL (InnoDB), a flipping bit causes a 16KB page checksum to be invalid. Because MySQL just dies encountering such errors in index or data, it will enter a restart loop, crashing again whenever the block is encountered again. You may start in a recovery mode and try to dump all data, hoping it was an index page, but it's risky because data may be corrupt. Put simply: A bit flip in InnoDB data means restore from backup. All of it. Happened to me last week - easy to replace slave DB. Non-ECC RAM is a very bad idea for databases, and a bad idea in general, also desktops with current sizes.
Apr
12
awarded  Popular Question
Apr
3
comment How does BTRFS compare to ZFS?
@Ysangkok: Thanks for the update, I'm actually using ZOL for quite some time now (RCs) and am impressed by the snapshot performance. Very good to have DKMS packages for Debian, I think I will deploy it on a few more systems.
Mar
25
awarded  Yearling
Oct
21
awarded  Revival
Oct
11
comment Is current SATA 6 gb/s equipment simply unreliable?
Also, two different controllers (LSI) tested. I think I have now replaced everything except the disks :-)