A Quick Guide to Understanding the Actual Dangers of Radiation

Posted on by

I’ve seen a lot of misleading and incorrect information on the TV when it comes to radiation exposure.

In college I had a co-op job at Diablo Canyon Nuclear Power Plant. That doesn’t make me a nuclear expert, but along with every other new employee at the plant I had to take a series of classes so that I understood the risks of radiation exposure, how to keep from getting irradiated, and what to do if things go Very Wrong. I’ve been reviewing some of that information so that I could give family and friends this quick guide to understanding what they should and should not be concerned about with the partial meltdowns in progress at the Fukushima Daiichi Nuclear Power Plant Complex in Japan. Hopefully after reading this you’ll have a better understanding of whether or not you are in any danger when you hear something on the news or read something on the Internet.

The first thing you need to understand is that there are two very different types of danger from radiation:

  • Radiation Exposure
  • Radioactive Contamination

Radioactive materials such as Uranium, Caesium-137[1] , and Iodine-131 emit high energy particles. When these particles hit your body they impart energy to your body. This is what is meant by Radiation Exposure. It’s similar to [2] the way a microwave oven imparts energy to a hot dog, or an EasyBake oven bakes a cake, or sitting out in the sun makes your skin tan (or, in my case, burn).

Radioactive Contamination is when radioactive materials actually get into your body, either through your skin or by being inhaled.

When it comes to Radiation Exposure there are three things that determine how much danger you’re in:

  • The strength of the source of radiation. (How many high energy particles does it emit per second? What type of particles does it emit? How energetic are those particles?)
  • Your distance from the source of radioactivity.
  • How much time you spend next to that source while it’s emitting radioactivity.

Strength: Different sources of radiation have different strengths, this is why Uranium, Caesium-137, and Iodine-131 are considered so dangerous, they’re strong sources of radiation, they emit a lot of very high energy particles that can damage human tissue.

Distance: If you’re standing right next to a 100W light bulb it’s very bright. If you’re 1000 yards away it’s dim. If you’re on the other side of town you can’t see it at all. With radioactive materials, the closer you are to a source of radiation the more high energy particles are going to hit your body. As you get farther away fewer particles hit your body. Get far enough enough away from the bulb and you can’t see it. Get far enough away from a radioactive source and there’s no danger.

Time: A chest X-Ray is a very intense burst of radiation, but the amount of time you’re exposed to that radiation is very short, so while there’s no danger from getting a single chest X-Ray, you don’t want to get one every hour of every day for weeks on end. If you stay out in the sun for an hour you might get a tan, stay out in the hot sun all day and you get burned. If you stroll past the Fukushima Daiichi Nuclear Power Plant you’ll get less radiation exposure than if you pull up a chair and sit there for a couple of hours. The amount of time you’re exposed to a radioactive source affects the dose of radiation you receive.

You may hear news people talking about how many “millisieverts of radiation” people are exposed to at Fukushima Daiichi. A millisievert (mSv) is a measurement based on the amount and type of radiation your body would be exposed to over some period of time. Any news story that quotes a sievert number without including the amount of time it takes to get that dosage is just spreading misleading information. If a news person quotes a sievert number without including the duration of the exposure they do not know what they are talking about and you are wasting your time listening to that news source.

Just like other metric measurements there are 1000 millisieverts in one sievert, so if you hear a news commentator mixing up millisieverts and sieverts you can safely change the channel – the commentator has no idea what they’re talking about.

If you hear the commentator talking about “radiation” without making clear whether they’re talking about exposure or contamination chances are the commentator has no idea what they’re talking about.

There is no safe dose of radiation exposure, but there are dose levels that will definitely cause you harm and there are dose levels that will kill you. If you get a dose of 250 mSv within one day you won’t even have any symptoms. Some people are going to show signs of radiation poisoning with a dose of 250-1000 mSv within one day. Anyone exposed to 1000-3000 mSv within one day will show signs of radiation poisoning. 3000-6000 mSv and you’re almost definitely going to die without medical treatment and probably going to die even with medical treatment. 6000-10000 will kill 95% of people exposed, over 10000 mSv within one day will kill anyone.

I saw a report on this morning that said that the radiation level outside of Fukushima Daiichi was 400 millisieverts (mSv). This is a completely meaningless number unless without a time measurement is included. Would someone get a dose of 400 mSv in an hour? In a day? In a minute? It’s not like a chest X-Ray where your exposure is limited to a few seconds, the plant leakage is on-going, so any dose levels have to be considered over some period of time.

According to an IAEA report it was 400 mSv per hour, but it was limited to a single location and during a single point in time on March 15. On that same day at 00:00 UTC the level observed was 11.9 mSv per hour and at 06:00 UTC it was 0.6 mSv per hour. If I had just listened to the TV news report of “400 millisieverts” — without knowing about the other measurements that were made or how long the 400 mSv measurement lasted — I’d be scared shitless. However, in context what this means is that if you were at Fukushima Daiichi standing right between reactor units 3 and 4 all day you’d be having a Bad Day and you’d have a higher risk of cancer for the rest of your life, but you wouldn’t fall over dead. If you were anywhere else on the planet you’d be fine.

In terms of Radiation Exposure, if you’re in Japan near the reactor complex the reactors themselves are the source of radiation you need to worry about.

If you’re not in Japan the source of radiation you need to worry about is the steam and debris being spewed out by the plant. As long as the wind is out to sea most of that debris is going into the Pacific Ocean, but some is going to make it across the ocean. You will hear reports that the amount of radiation from this cloud represents a very low dose, and that there is nothing to worry about. This is half true. In terms of radiation exposure, the cloud is not a major threat. The problem is radioactive contamination.

The contamination is being spread across northern Japan and across the Pacific Ocean. If you get contaminated with radioactive debris, that means that in the spot on your body where that debris enters your skin or gets lodged in your lungs, that one spot is going to continue to get dosed by radiation for a very long time. That is the major concern of contamination – long term exposure to radiation of a single spot on your body. The dosage per hour can be very low, but because the duration is so long (sometimes years if the particle gets stuck in your lungs) and the focus point of the energy is so small the danger is much larger.

The two major things to worry about when it comes to contamination are:

  • What type radioactive material did you get on (or in) your body?
  • How much radioactive material did you get on (or in) your body?

The type of material will tell you how strong of a source of radiation you’re dealing with. The more material there is, the more high energy particles it will emit per second. Most highly-radioactive materials are also heavy, so they’ll end up in the ocean or in the soil of northern Japan, but some will make it across the ocean. Keeping yourself from getting contaminated with this radioactive debris is what you want to be concerned about.

Before you start freaking out, consider that during the 1950’s the U.S. Army was busy blowing holes in Nevada and New Mexico with nuclear weapons and the fallout from those explosions drifted over the Eastern United States. The debris from those explosions was far, far more dangerous than what’s coming out of Japan these days. Most of the people who lived through the 1950’s did not die from radiation poisoning, and the cancer rate in the United States has been declining for the past several decades.

So yes, there’s a danger, but it’s not huge and it’s probably not going to kill you tomorrow. The farther you are from Fukushima Daiichi the less danger you’re in. Right next to it or just downwind of the plant, lots of danger. Across the ocean, right now, not so much. I would not want to be living in Northern Japan right now, but I’m not too worried about living in Northern California.

However, conditions change. When you watch or read news reports look for terms like “millisieverts per hour”, “contamination” and “fallout” and pay careful attention to where these measurements were made. If the measurement is 400 millisieverts per hour during one particular hour near the reactor in Japan — and you’re in San Francisco — you are not in any danger. If the report says “radioactive cloud headed for Los Angeles” — but gives no measurement of radiation strength or type of contamination present – turn off the TV and go find a news source that has useful news and not useless scaremongering.

And if a report says that a rainstorm is washing radioactive particles out of the sky, stay out of the rain.

The people of Japan have been hit by an earthquake, a tsunami, and now nuclear radiation and contamination. If you want to help, donate to the Red Cross today. Want to do more? One of the first things done for victims of acute radiation poisoning is a blood transfusion, so go to your local Red Cross office and give blood. Your blood donation might be used to help save someone’s life in Japan, but even if it isn’t, it will help save someone.

[1] “Caesium” is the spelling recommended by the International Union of Pure and Applied Chemistry (IUPAC). The American Chemical Society (ACS) has used the spelling “cesium” since 1921, following Webster’s Third New International Dictionary. I prefer the spelling “caesium”, so that’s what I use.

[2] I say similar to, and emphasize the words similar to, because they’re not the same, but the similarity to these other forms of (non-ionizing) radiation that people have everyday experience with is one way that people can wrap their heads around this idea. I hope no one misunderstands the words similar to and takes them to mean the same as, because that’s not what similar to means.

Turn off trackpad pinch-to-zoom on Firefox on Mac OS X

Posted on by

If you browse the web using Firefox on a Mac laptop you’ve probably brushed the track pad the wrong way and accidentally zoomed in on content. I’ve never used the pinch gesture to zoom in on purpose, it always happens by accident, then I have to press Command-0 to reset the screen back to normal.

I tried Googling for an answer, and found a bunch of people annoyed by the same experience, but no solutions.

I thought there might be a Firefox setting to control this, so I looked and I found one. Here’s what I did:

  • I typed “about:config” into the Firefox location bar to get to the configure-anything screen.
  • I clicked past the “this voids your warranty” disclaimer.
  • Type “zoom” in the search bar to find settings related to zoom.
  • The zoom in / zoom out gesture settings are browser.gesture.pinch.in and browser.gesture.pinch.out. Click browser.gesture.pinch.in to edit the setting. It’s usually set to “cmd_fullZoomReduce” and I changed that to “cmd_fullZoomReduce-disable”. (That way if I ever want to re-enable it all I have to do is remove the “-disable” part.)
  • Click browser.gesture.pinch.out and change its setting from “cmd_fullZoomEnlarge” to “cmd_fullZoomEnlarge-disable”.

That’s it. No more annoying track pad zoom.

Hope you find this useful.

Increasing the size of an LVM Physical Volume (PV) while running multipathd — without rebooting

Posted on by

If you’re using the Linux Logical Volume Manager (LVM) to manage your disk space it’s easy to enlarge a logical volume while a server is up and running. It’s also easy to add new drives to an existing volume group.

But if you’re using a SAN the underlying physical drives can have different performance characteristics because they’re assigned to different QOS bands on the SAN. If you want to keep performance optimized it’s important to know what physical volume a logical volume is assigned to — otherwise you can split a single logical volume across multiple physical volumes and end up degrading system performance. If you run out of space on a physical volume and then enlarge a logical volume you will split the LV across two or more PVs. To prevent this from happening you need to enlarge the LUN, tell multipathd about the change, then enlarge the PV, then enlarge the LV, and finally enlarge the file system.

I have three SANs at the company where I work (two Pillar Axioms and a Xyratex) which are attached two two fibrechannel switches and several racks of blade servers. Each blade is running an Oracle database with multiple physical volumes (PVs) grouped together into a single LVM. The PVs are tagged and as logical volumes (LVs) are added they’re assigned to the base physical volume with the same tag name as the logical volume. That way we can assign the PV to a higher or lower performance band on the SAN and optimize the database’s performance. Oracle tablespaces that contain frequently-accessed data get assigned to a PV with a higher QOS band on the SAN. Archival data gets put on a PV with a lower QOS band.

We run OpenSUSE 11.x using multipathd to deal with the multiple fiber paths available between each blade and a SAN. Since each blade has 2 fiber ports for redundancy, which are attached to two fiber switches, each of which is cross-connected to 2 ports on 2 different controllers on the SAN, so there are 4 different fiber paths that data can take between the blade and the SAN. If any path fails, or one port on a fiber card fails, or one fiber switch fails, multipathd re-routes the data using the remaining data paths and everything keeps working. If a blade fails we switch to another blade.

If we run out of space on a PV I can log into the SAN’s administrative interface and enlarge the size of the underlying LUN, but getting the operating system on the blade to recognize the fact that more physical disk space was available is tricky. LVM’s pvresize command would claim that it was enlarging the PV, but nothing would happen unless the server was rebooted and then pvresize was run again. I wanted to be able to enlarge physical volumes without taking a database off-line and rebooting its server. Here’s how I did it:

  • First log into the SAN’s administrative interface and enlarge the LUN in question.
  • Open two xterm windows on the host as root
  • Gather information – you will need the physical device name, the multipath block device names, and the multipath map name. (Since our setup gives us 4 data paths for each LUN there are 4 multipath block device names.)
  • List the physical volumes and their associated tags with pvs -o +tags: 
    # pvs -o +tags
  PV         VG     Fmt  Attr PSize   PFree   PV Tags                
  /dev/dm-1  switch lvm2 a-   500.38G 280.38G db024-lindx,lindx      
  /dev/dm-10 switch lvm2 a-     1.95T 801.00G db024-ldata,ldata      
  /dev/dm-11 switch lvm2 a-    81.50G      0  db024-mindx,mindx      
  /dev/dm-12 switch lvm2 a-   650.00G 100.00G db024-reports,reports  
  /dev/dm-13 switch lvm2 a-    51.25G  31.25G db024-log,log          
  /dev/dm-14 switch lvm2 a-   450.12G  50.12G db024-home,home        
  /dev/dm-15 switch lvm2 a-     1.76T 342.00G db024-q_backup,q_backup
  /dev/dm-16 switch lvm2 a-     1.00G 640.00M db024-control,control  
  /dev/dm-2  switch lvm2 a-   301.38G 120.38G db024-dbs,dbs          
  /dev/dm-3  switch lvm2 a-   401.88G 101.88G db024-cdr_data,cdr_data
  /dev/dm-5  switch lvm2 a-   450.62G 290.62G db024-archlogs,archlogs
  /dev/dm-6  switch lvm2 a-    40.88G  22.50G db024-boot,boot        
  /dev/dm-7  switch lvm2 a-    51.25G   1.25G db024-rbs,rbs          
  /dev/dm-8  switch lvm2 a-    51.25G  27.25G db024-temp,temp        
  /dev/dm-9  switch lvm2 a-   201.38G 161.38G db024-summary,summary
  • Find the device that corresponds to the LUN you just enlarged, e.g. /dev/dm-11
  • Run multipath -ll, find the device name in the listing. The large hex number at the start of the line is the multipath map name and the sdX block devices after the device name are the multipath block devices. So in this example the map name is 2000b080112002142 and the block devices are sdy, sdan, sdj, and sdbc: 
    2000b080112002142 dm-11 Pillar,Axiom 500                 
[size=82G][features=1 queue_if_no_path][hwhandler=0][rw] 
\_ round-robin 0 [prio=100][active]                      
 \_ 0:0:5:9  sdy        65:128 [active][ready]           
 \_ 1:0:4:9  sdan       66:112 [active][ready]           
\_ round-robin 0 [prio=20][enabled]                      
 \_ 0:0:4:9  sdj        8:144  [active][ready]           
 \_ 1:0:5:9  sdbc       67:96  [active][ready]
  • Next get multipath to recognize that the device is larger:
    • For each block device do echo 1 > /sys/block/sdX/device/rescan: 
      # echo 1 > /sys/block/sdy/device/rescan
# echo 1 > /sys/block/sdan/device/rescan
# echo 1 > /sys/block/sdj/device/rescan
# echo 1 > /sys/block/sdbc/device/rescan
    • In the second root window, pull up a multipath command line with multipathd -k
    • Delete and re-add the first block device from each group. Since multipathd provides multiple paths to the underlying SAN, the device will remain up and on-line during this process. Make sure that you get an ‘ok’ after each command. If you see ‘fail’ or anything else besides ‘ok’, STOP WHAT YOU’RE DOING and go to the next step. 
      multipathd> del path sdy                                             
ok                                                                   
multipathd> add path sdy                                             
ok                                                                   
multipathd> del path sdj                                             
ok                                                                   
multipathd> add path sdj                                             
ok
    • If you got a ‘fail’ response:
      • Type exit to get back to a command line.
      • Type multipath -r on the command line. This should recover/rebuild all block device paths.
      • Type multipath -ll | less again and verify that the block devices were re-added.
      • At this point multipath may actually recognize the new device size (you can see the size in the multipath -ll output). If everything looks good, skip ahead to the pvresize step.
    • In the first root window run multipath -ll again and verify that the block devices were re-added: 
      2000b080112002142 dm-11 Pillar,Axiom 500                 
[size=82G][features=1 queue_if_no_path][hwhandler=0][rw] 
\_ round-robin 0 [prio=100][active]                      
 \_ 1:0:4:9  sdan       66:112 [active][ready]           
 \_ 0:0:5:9  sdy        65:128 [active][ready]           
\_ round-robin 0 [prio=20][enabled]                      
 \_ 1:0:5:9  sdbc       67:96  [active][ready]           
 \_ 0:0:4:9  sdj        8:144  [active][ready]
    • Delete and re-add the remaining two block devices in the second root window: 
      multipathd> del path sdan
ok                       
multipathd> add path sdan
ok                       
multipathd> del path sdbc
ok                       
multipathd> add path sdbc
ok
    • In the first root window run multipath -ll again and verify that the block devices were re-added.
    • Tell multipathd to resize the block device map using the map name: 
      multipathd> resize map 2000b080112002142
ok
    • Press Ctrl-D to exit multipathd command line.
  • In the first root window run multipath -llagain to verify that multipath sees the new physical device size. The device below went from 82G to 142G: 
    2000b080112002142 dm-11 Pillar,Axiom 500
[size=142G][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=100][active]
 \_ 0:0:5:9  sdy        65:128 [active][ready]
 \_ 1:0:4:9  sdan       66:112 [active][ready]
\_ round-robin 0 [prio=20][enabled]
 \_ 0:0:4:9  sdj        8:144  [active][ready]
 \_ 1:0:5:9  sdbc       67:96  [active][ready]
  • Finally, get the LVM volume group to recognize that the physical volume is larger using pvresize: 
    # pvresize /dev/dm-11
  Physical volume "/dev/dm-11" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized
# pvs -o +tags
  PV         VG     Fmt  Attr PSize   PFree   PV Tags
  /dev/dm-1  switch lvm2 a-   500.38G 280.38G db024-lindx,lindx
  /dev/dm-10 switch lvm2 a-     1.95T 801.00G db024-ldata,ldata
  /dev/dm-11 switch lvm2 a-   141.50G  60.00G db024-mindx,mindx
  /dev/dm-12 switch lvm2 a-   650.00G 100.00G db024-reports,reports
  /dev/dm-13 switch lvm2 a-    51.25G  31.25G db024-log,log
  /dev/dm-14 switch lvm2 a-   450.12G  50.12G db024-home,home
  /dev/dm-15 switch lvm2 a-     1.76T 342.00G db024-q_backup,q_backup
  /dev/dm-16 switch lvm2 a-     1.00G 640.00M db024-control,control
  /dev/dm-2  switch lvm2 a-   301.38G 120.38G db024-dbs,dbs
  /dev/dm-3  switch lvm2 a-   401.88G 101.88G db024-cdr_data,cdr_data
  /dev/dm-5  switch lvm2 a-   450.62G 290.62G db024-archlogs,archlogs
  /dev/dm-6  switch lvm2 a-    40.88G  22.50G db024-boot,boot
  /dev/dm-7  switch lvm2 a-    51.25G   1.25G db024-rbs,rbs
  /dev/dm-8  switch lvm2 a-    51.25G  27.25G db024-temp,temp
  /dev/dm-9  switch lvm2 a-   201.38G 161.38G db024-summary,summary

    pvs shows that /dev/dm-11 is now 141.5G.

At this point you can enlarge any logical volumes residing on the underlying physical volume without splitting the logical volume across multiple (non-contiguous) physical volumes using lvresize and enlarge the file system using the file system tools, e.g. resize2fs.

If you ran out of space, your LVs were split across multiple PVs, and you need to coalesce a PV onto a single LV use pvmove to move the physical volume to a single device.

Hope you find this useful.

Eliminating PXE Boot “Missing parameter in config file” Error Messages

Posted on by

I’d recently made a bunch of changes to my company’s server build scripts, making changes that automatically generate system builds for a variety of operating systems and CPU architectures. We use PXE Boot to boot servers, then install images from a central install server which is running OpenSUSE 11.1.

After I made the changes I started seeing the error message “Missing parameter in config file” at boot:

XELINUX 3.07 0x41e470ae  Copyright (C) 1994-2005 H. Peter Anvin                 
Missing parameter in config file.                                               
Missing parameter in config file.                                               
Missing parameter in config file.                                               
Missing parameter in config file.                                               
Missing parameter in config file.                                               
Missing parameter in config file.                                               
Missing parameter in config file.                                               
Missing parameter in config file.                                               
boot:

Everything worked just fine, we had no problems booting or building servers, but the error messages seemed to indicate that there was a problem. I searched the net to see if anyone else was having this problem, and many people were, but no one seemed to have a good answer as to what was causing the error message.

Our pxelinux.cfg/default config file lists about a hundred different boot options, so I made a backup copy and started deleting portions of pxelinux.cfg/default to see if I could reduce the number of errors.

I managed to reduce the number of errors, but couldn’t find anything in the lines I’d deleted that would cause a problem — I was deleting working configurations from the list, and I couldn’t figure out why a working configuration would cause an error message.

I finally figured it out — it was the comment blocks that I’d added. Something is buggy about the way that PXE parses comment lines. I’d commented out some old labels and even though every line started with “#”, those were the lines that were causing the “Missing parameter in config file” errors.

To solve the problem, I edited pxelinux.cfg/default, deleted blank lines in-between comments and labels, deleted blank lines between comments, deleted spaces between “#” and the start of any comment text, deleted old labels that had previously been commented out, and restarted atftpd.

By simplifying the comment lines and deleting old blocks of commented-out code I eliminated the error messages. I couldn’t believe that comment lines could be causing errors, so I tried various combinations of edits on the pxelinux.cfg/default file, restarting atftpd and rebooting a spare server about 30 times, but the only thing that eliminated the error messages was removing comment lines and blank lines from pxelinux.cfg/default.

Hope you find this useful.