Live data from Hacker News

A Google Cloud support engineer solves a tough DNS case

cloud.google.com

201–210 of 283 posts

Re: A Google Cloud support engineer solves a tough DNS case

#201

" When sk_rcvbuf gets close to 2^31, adding the size of the packet can cause an integer overflow. And since it’s an int it becomes a negative number, therefore the condition is true when it should be false (for more, also check out this discussion of signed magnitude representation). " And this is why you don't generally use signed numbers in systems code, unless you specifically need negative numbers. And why you gr…

Signed or unsigned doesn’t matter much both can overflow. I actually started putting assertion checks about overflow issues almost everywhere but it requires great discipline. I wonder if there is a better solution available.

If you can allow yourself this kind of performance regression, you can compile in GCC or clang with `-fsanitize=signed-integer-overflow`, this will do runtime checks.

Re: A Google Cloud support engineer solves a tough DNS case

#202

Earlier quoted context omitted.

Those are not safe to treat as equivalent, even if it might work in theory. You should always cast as narrowly as possible, and when you see code doing otherwise, look very carefully for bugs. If A + (cast)B is a correct form, then (cast)(A + B) is generally an inappropriate form. As you note, it’s possible it will happen to work, but it’s not good form.

Yes I qualified it at the end why the former is the correct solution and not the latter.

I figured that "in reality this would have worked too" is a easy phrase to misinterpret as "this would have worked" (assuming they miss the context a paragraph later), and so the reply helps ensure that others do not misread it as I initially did.

Re: A Google Cloud support engineer solves a tough DNS case

#203

Earlier quoted context omitted.

One of my computers has been aptly named 'THESEUS' due to what was replaced on it. By the time it was repaired to an acceptable level, the only original component remaining was the chassis.

Heh... that reminds me of my favourite troubleshooting story! We had a customer with regularly failing tape backups. CRC errors, verify pass failures, even failed writes, and so forth. We replaced the tapes with new ones. Same issues. We replaced the tape drive with a new one. Still the same problems. We replaced the internal ribbon cable and the SCSI controller. No luck. Firmware flashed everything. Didn't help. New…

Many would have hit the ground too! I'm twitching...

Re: A Google Cloud support engineer solves a tough DNS case

#205
post #95

Earlier quoted context omitted.

It is indeed folly to assume that cattle have no identity. There's an internally famous video inside Google in which a particular well-known machine was unracked, dragged out into a field, and ceremonially smashed to pieces by some hardware techs. Sometimes a machine just takes an arrow to the knee and it's never the same again. Then there are all the uncontrolled or unrecorded differences between machines: the ones…

One of my computers has been aptly named 'THESEUS' due to what was replaced on it. By the time it was repaired to an acceptable level, the only original component remaining was the chassis.

Reminds me of the saying, "I have used this broom for 20 years. I only needed to change the broom head 20 times and the broom stick 10 times.".

Re: A Google Cloud support engineer solves a tough DNS case

#206
post #95

Earlier quoted context omitted.

It is indeed folly to assume that cattle have no identity. There's an internally famous video inside Google in which a particular well-known machine was unracked, dragged out into a field, and ceremonially smashed to pieces by some hardware techs. Sometimes a machine just takes an arrow to the knee and it's never the same again. Then there are all the uncontrolled or unrecorded differences between machines: the ones…

> There's an internally famous video inside Google in which a particular well-known machine was unracked, dragged out into a field, and ceremonially smashed to pieces by some hardware techs. Eyy what would I search on moma to find this video?

Huh, I can't find it.

I can confirm I've read the same thing though, years back.

Re: A Google Cloud support engineer solves a tough DNS case

#207

Earlier quoted context omitted.

Here you go: https://cloud.google.com/support#support-plans $250/month/dev is the minimal for phone calls on technical issues, $150k + 4% of GCP spend for 'come running' support. There're more details here https://cloud.google.com/support/docs/procedures#additional_... though they use the old names for the support tiers.

It seems like the blog post talks about a written case report, which the 100$ tier has access to, albeit with 4 hour first response instead of 1 hour. So it is possible that you could get your case escalated to such an in depth debugging with that tier?

I've seen free tier tickets get escalated to product engineering teams for investigations about sub $100 charges.

Re: A Google Cloud support engineer solves a tough DNS case

#208
post #95

Earlier quoted context omitted.

It is indeed folly to assume that cattle have no identity. There's an internally famous video inside Google in which a particular well-known machine was unracked, dragged out into a field, and ceremonially smashed to pieces by some hardware techs. Sometimes a machine just takes an arrow to the knee and it's never the same again. Then there are all the uncontrolled or unrecorded differences between machines: the ones…

back when we where buying hardware for big (at the time) intranet. All the servers where brought of the same batch of suns production line, I recall our sysadmin saying he rely wanted to do the same for the disks ie case of identical drives

Others have mentioned the problems with this strategy, but getting drives with the same firmware is done routinely to avoid having slightly different behavior in the RAID set.

Re: A Google Cloud support engineer solves a tough DNS case

#209

Earlier quoted context omitted.

Yes I qualified it at the end why the former is the correct solution and not the latter.

I figured that "in reality this would have worked too" is a easy phrase to misinterpret as "this would have worked" (assuming they miss the context a paragraph later), and so the reply helps ensure that others do not misread it as I initially did.

Yes ! thank you.

Re: A Google Cloud support engineer solves a tough DNS case

#210

" When sk_rcvbuf gets close to 2^31, adding the size of the packet can cause an integer overflow. And since it’s an int it becomes a negative number, therefore the condition is true when it should be false (for more, also check out this discussion of signed magnitude representation). " And this is why you don't generally use signed numbers in systems code, unless you specifically need negative numbers. And why you gr…

What happens when some dumbledork sets it to 2^32+1?
Post reply on HN