I tracked the problem down to a setting in Compiz, the screen compositing tool used by many Linux desktop environments, so if you’re using KDE or Unity with Compiz and you’re finding self-resizing windows irritating this fix should work for you as well.

To fix the problem you need to install the CompizConfig Settings Manager, so fire up Synaptic Package Manager and search for “compizconfig-settings-manager” and install it.

Once installed, if you’re using Gnome go to Applications > System Tools > Preferences and click “CompizConfig Settings Manager” to start the tool.

Scroll down to “Window Management.”

Uncheck “Place Windows”.

Leave “Grid” checked, but click the word “Grid” to get the Grid settings, then go to the Edges tab and change all Resize Actions to “None”.

Click Back.

Now your desktop will do what you tell it to do, rather than second-guessing you and doing something that you do not want.

One thing that you can now do (that you probably really don’t want) is to have the title bar (and it’s controls) move off-screen, which means you can’t move or resize the window unless you Alt-right-click on it. To fix that issue:

Check the “Put” plugin.

Click the word “Put” to bring up more options, go to the “Misc Options” tab, check “Avoid Offscreen”, click Back, then Close Window.

Hope you find this useful.

If you already know what a symlink is then you don’t need to read the rest of this article. If you want a better explanation, read on…

I use the Thunderbird e-mail client to read mail stored on my company’s IMAP mail server. I have a lot of filters set up that sort the mail into different folders, and Thunderbird stores the filter definitions in a file called msgFilterRules.dat. I read mail on different machines, some running various Linux distros and some running Mac OS X. I wanted all of the different machines to use the same rules for filtering e-mail into different folders, and if I make changes to the filters on one host I want those changes to take effect on all of the other hosts as well.

To do this I first set up a Dropbox account and installed the Dropbox software on my different machines, so now there’s a directory called “Dropbox” in my home directory that is synchronized between all of my different machines. I moved my filter file into the Dropbox directory and symlinked that to the location where Thunderbird expects to find the filter rules.

The step-by-step explanation if you want to do this:

Set up Dropbox on all of your machines.

Shut down Thunderbird if it’s running.

Start up a terminal window.

Find the msgFilterRules.dat file that you want to use as your “master” copy. On both my Mac laptop and Linux hosts the file is stored in ~/.thunderbird/[profile name]/ImapMail/[imap server name]/, where [profile name] is your Thunderbird profile name on that host, usually some random characters followed by ‘.default’. (Type cat ~/.thunderbird/profiles.ini if you want to see all of your profile names.)

Make a backup copy of the msgFilterRules.dat file:

cd ~/.thunderbird/[profile name]/ImapMail/[imap server name]/

cp msgFilterRules.dat msgFilterRules.dat.backup

Move the filter file to Dropbox:

mv msgFilterRules.dat ~/Dropbox/

Symlink the Dropbox copy of the file to the current directory, where Thunderbird expects to find it:

ln -s ~/Dropbox/msgFilterRules.dat .

Verify that the symlink was created correctly:

ls -al

You should see a line that looks like:

lrwxrwxrwx  1 earl users        37 Oct 25 21:12 msgFilterRules.dat -> /home/earl/Dropbox/msgFilterRules.dat

Now the machine you’re on is using the Dropbox copy of the filter file. To set this up on your other machines:

Verify that the file exists in the ~/Dropbox directory:

ls -al ~/Dropbox

Get to the directory where the filter file lives, remove the local copy, then create the symlink:

cd ~/.thunderbird/[profile name]/ImapMail/[imap server name]/

rm msgFilterRules.dat

ln -s ~/Dropbox/msgFilterRules.dat .

One word of warning: Thunderbird reads the filters into memory when it starts, and writes them back to disk when it exits. That means that if you have two hosts and Thunderbird is running on both of them, the last host that exits will write it’s version of the filters to disk. So if you make a change to the filters on one host and exit from Thunderbird, then exit from Thunderbird on the second host, the older filters on second host will overwrite the filter you just added. Because of this, I recommend exiting from Thunderbird whenever you leave your computer. I added a “killall thunderbird-bin” that runs from cron at 2am just to make sure that my copy at work isn’t running if I check mail from home in the morning.

The problem is with the Oxygen widget style. On a host running OpenSUSE 11.4 you can change this by going to:

Applications > Configure Desktop > Application Appearance > Style

Then set “Widget Style” to any style except “Oxygen”. Click Apply.

Problem solved.

Users of the Gnome 3 desktop shell are reporting that for some video card and monitor combinations the Gnome 3 screen saver, after getting a key press / mouse movement that should prompt you for your password to unlock the screen:

• Won’t unlock the screen at all.
• Will display a mouse pointer but no password prompt.
• Will display your original screen and all open documents (without prompting for a password) but will not allow you to click on anything, basically appearing as a locked-up desktop.

My setup reliably produces situation #3.

To unlock a locked-up desktop:

• Ctrl-Alt-F1 will give you a text-based terminal login.
• Log in with your user name and password.
• Type: “killall gnome-screensaver”
• Ctrl-Alt-F7 to get back to the (now unlocked) Gnome 3 desktop.

To replace the Gnome 3 screen saver with something less buggy:

• Activities > Applications > Other > Synaptic Package Manager
• Quick filter: xscreensaver
• Right click ‘xscreensaver’ and select ‘Mark for Installation’
• Click ‘Apply’ to install
• Activities > Applications > System Tools  > System Settings > Screen
• Set “Turn off after” to ‘Never’ and “Lock” to ‘OFF’. This disables gnome-screensaver.
• Activities > Applications > All > Screensaver
• Follow the prompts to activate xscreensaver

If you try to uninstall gnome-screensaver Synaptic Package Manager will also want to uninstall gnome and gnome-core, which is a bad idea if you want to run Gnome. Gnome will always start gnome-screensaver even if you have it disabled, and xscreensaver won’t run if gnome-screensaver is running. So you basically need to kill gnome-screensaver after Gnome has started and then start xscreensaver. You can do this by adding a startup program:

• Activities > Applications > Other > Startup Programs > Add
• Name: “Screen Saver”
• Command: “sleep 30; killall gnome-screensaver; sleep 5; xscreensaver”
• Comment: “Kill gnome-screensaver, start xscreensaver”
• Click “Add”

Hope you find this useful.

sudo apt-get install gnome-shell

To use Gnome 3 instead of Unity: when you log in, click the “gear” above your password. Select “Gnome”, log in.

After you get tired of “click Activities, find the window you want, click the window” every time you want to switch from one window to another, and you decide you really need a taskbar again to maintain your sanity, start up a terminal and type:

sudo apt-get install tint2
tint2 &

You now have a taskbar again. To get it to appear every time you start Gnome 3 go to Activities > Applications > Other > Startup Applications, then click “Add”, Name: “tint2 task bar”, Command: “tint2″, click “Save”.

Done.

Hope you find this useful.

• Go to Tools > Autocorrect Options
• Select the Localized Options tab
• Click the button under Start Quote. If you’re using the Basic Latin character set, scroll all the way to the top of the character set display and click the ” box (third box from the top left row, next to the !). If you are using some other character set try searching near the top of the set for the ” character.
• Click OK
• Click the button under End Quote. Scroll all the way to the top of the character set display and click the ” box (third box from the top left row, next to the !)
• Click OK
• Click OK

Smart quotes are now off for the document that you’re working on. They will also be off for any new documents that you create, including spreadsheets and files created by other Libre Office applications.

To get rid of smart quotes already in a document:

• Highlight any start smart quote and copy it (Ctrl-C or File > Copy)
• Select Edit > Find & Replace
• Paste the smart quote into the Search for box
• Type ” in the Replace with box
• Click the Replace All button
• Click Close
• Repeat these steps using a copy of the end smart quote

So I logged into my workstation from home and ran:

> sudo apt-get install update-manager-core
> sudo do-release-upgrade

The upgrade script warned me that I was using ssh and asked if I was sure I wanted to continue. I said “Y”, and a little while later the upgrade manager was busy downloading upgrade packages.

I planned to check it a couple of times that night, answer any package upgrade questions that popped up, and then in the morning when I got to work the upgrade would be complete.

Of course what actually happened was that I got side-tracked onto some other problem that night, forgot about the upgrade in progress, and when I got to work the next day my workstation was in a state of limbo, with the upgrade halfway complete, waiting for me to answer some question on the screen — at my house.

Luckily the Ubuntu developers who created the ssh upgrade process run that upgrade inside of a screen session. As the screen pages states, “Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells).”

So at work all I had to do was get the list of current screen sessions:

> sudo screen -list
There are screens on:
        9129.ubuntu-release-upgrade-screen-window       (05/17/2011 08:50:08 PM)        (Attached)
2 Sockets in /var/run/screen/S-root.

Invoke screen using the “-d -r sessionowner/[pid.tty.host]” flags:

> sudo screen -d -r root/9129.ubuntu-release-upgrade-screen-window

… and I could pull up the screen at work that had been displaying at my home. Once I answered the remaining questions about whether to keep my custom configuration files or use the new, packaged configuration files my workstation rebooted and the latest version of Ubuntu booted right up.

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.

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.

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:

  multipathd> del path sdy
  ok
  multipathd> add path sdy
  ok
  multipathd> del path sdj
  ok
  multipathd> add path sdj
  ok  

• 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 -ll again 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.