Earlier quoted context omitted.
HN isn't a mission-critical business. It's a fun, experimental distraction (albeit one that we all rate very highly, of course).
> It's a fun, experimental distraction It seems to incur maintenance costs and reputation hits that are avoidable though, isn't that reason enough to invest some time in building a reliable solution?
Tell HN: Server Status
31–40 of 124 posts
Re: Tell HN: Server Status
#32Hoping the box has ECC ram, otherwise zfs, too, can be unreliable (http://research.cs.wisc.edu/adsl/Publications/zfs-corruption...)
Re: Tell HN: Server Status
#33I'm sure it has been asked many times before, but I'd love to hear the latest thinking... Why in 2013 is HN still running on bespoke hardware and software? If a startup came to you with this sort of legacy thinking you'd laugh them out of the room.
They even went out of their way to get the fastest single core xeon possible, which is a fairly mid-range CPU, singe they care about process performance vs. overall.
Re: Tell HN: Server Status
#34Earlier quoted context omitted.
> It's a fun, experimental distraction It seems to incur maintenance costs and reputation hits that are avoidable though, isn't that reason enough to invest some time in building a reliable solution?
No-one's going to say "Yeah I was going to apply to YC but HN keeps going down so I don't think I will after all".
Re: Tell HN: Server Status
#35Raidz2 is not fast. In fact, it is slow. Also, it is less reliable than a two way mirror in most configurations, because recovering from a disk loss requires reading the entirety of every other disk, whereas recovering from loss in a mirror requires reading the entirety of one disk. The multiplication of the probabilities don't work out particularly well as you scale up in disk count (even taking into account that raidz2 tolerates a disk failure mid-recovery). And mirroring is much faster, since it can distribute seeks across multiple disks, something raidz2 cannot do. Raidz2 essentially synchronizes the spindles on all disks.
Raidz2 is more or less suitable for archival-style storage where you can't afford the space loss from mirroring. For example, I have an 11 disk raidz2 array in my home NAS, spread across two separate PCIe x8 8-port 6Gbps SAS/SATA cards, and don't usually see read or write speeds for files[1] exceeding 200MB/sec. The drives individually are capable of over 100MB/sec - in a non-raidz2 setup, I'd be potentially seeing over 1GB/sec on reads of large contiguous files.
Personally I'm going to move to multiple 4-disk raid10 vdevs. I can afford the space loss, and the performance characteristics are much better.
[1] Scrub speeds are higher, but not really relevant to FS performance.
Re: Tell HN: Server Status
#36I didn't realize HN had enough disk storage needs to need more than one drive. I guess you could have 1+2 redundancy or something.
Re: Tell HN: Server Status
#37I'm sure it has been asked many times before, but I'd love to hear the latest thinking... Why in 2013 is HN still running on bespoke hardware and software? If a startup came to you with this sort of legacy thinking you'd laugh them out of the room.
Yes it may seem archaic, but it a real server has real disk IO, something which on amazon and the like doesn't come cheap
Re: Tell HN: Server Status
#38may i ask where are the machines hosted? is that on AWS? if not, why don't you move to a more reliable hosting, like AWS?
Ah yes, because AWS has worked out so well for the reddit folk. :-)
Re: Tell HN: Server Status
#39By tolerating the loss of two disks, do you mean raidz2 or do you mean 3-way mirror? Raidz2 is not fast. In fact, it is slow. Also, it is less reliable than a two way mirror in most configurations, because recovering from a disk loss requires reading the entirety of every other disk, whereas recovering from loss in a mirror requires reading the entirety of one disk. The multiplication of the probabilities don't work…
And it all pretty much impacts your customer. We've all suffered under the 4-hour mirror rebuild, the whole machine made inoperable by the constant disk load. The only way to alleviate that, is to design extra bandwidth (e.g. another cable and controller) that's used exclusively for recovery.
I've designed/build storage that worked that way, but it was for enterprise. The home user doesn't want to pay for extra bandwidth and then not use it most of the time. And if the DO use it, then they notice when a rebuild is triggered, and complain. Its catch-22.
Re: Tell HN: Server Status
#40Earlier quoted context omitted.
Kids these days. Next thing you say you can't whistle at 2400 baud. Sheesh.
2400 Hz, if I'm not mistaken. Baud indicates how many signals you can send in a second. Hz is the wave frequency, which you have to mimic for the signaling tones.