AIX Down Under
If you need to move the entire contents of a file system, and the underlying storage doesn't need to change, you might as well just change the mount point. When you change the mount point of a file system, you effectively move all the files and directories that sail in it. Wouldn't it be wonderful if you could relocate your house and family just by slapping on a new sign on the gates of your city. In effect, that's what happens when you change the mount point.
When you want to use a new mount point - effectively rename a file system's - it doesn't take effect until you unmount the old one. And you can't do that if the file system is in use. And if a file system has nested file systems within it, then they have to come down first.
So here's the procedure. This is taken from my article Moving Mounts in the .
For more information about changing file systems, see the rest of the article.
I recommend subscribing to theIBM Systems Magazine, Power Systems edition (AIX and IBM i). It has a wealth of news and information about AIX in very accessible format. It includes a weekly blog post - AIXChange - from the indefatigable Rob McNelly. Always a great read.
AnthonyEnglish 270000RKFN Marcações:  fs chfs logical_volume_manager lslv file_system lv aix lvm 13.555 Visualizações
The Oracle DBAs asked for the redo logs file system to have a new agblksize. I recall that Jaqui Lynch recommended this in her 2008 article In Tune with Oracle:
A new file system
Changing the agblksize meant recreating the file system. Ordinarily, I would have done this by removing the old file system using rmfs. The rmfs command would blow away the original file system's underlying logical volume, and the lv would need to be recreated, and then a new file system. But a colleague of mine found a better way: creating just the new file system on the existing lv:
This will destroy the contents of the existing file system, so you need to back up anything you want to keep first.
First, he backed up the redo logs (with the Oracle database down!)
New file system
Then he created a new filesystem with agblksize=512 as follows:
mkfs -s 4G -o agblksize=512 /dev/redo
You can check the new filesystem agblksize with the command: lsfs -q
After this, mount the new /redo filesystem:
mount /redoAnd copy the redo logs back from /redo_old to /redo.
Just the mount point
You don't need to create a new file system if you just want to change the mount point. To change the directory the file system is mounted on, you can use the chfs command
chfs -m /new_mount_point /old_mount_pointINLINE JFS logs
But sometimes you do need to create a new file system. Apart from setting the agblksize, you might want to create a new file system to convert it to use INLINE jfs logs, or to allow internal snapshots.
If you need to change the logical volume layout itself, you may need to use the chlv command to rename it (-n flag) or to increase its size. Or you might need to rebuild it altogether, for example when you're converting from software striping to a hardware RAID. But if you want to keep the lv and just recreate the file system itself, my colleague's procedure should be just what the doctor ordered.
AnthonyEnglish 270000RKFN Marcações:  mount aix chlv chfs log=null ram_disk nmon tuning io no_logging disk topas performance iostat iowait rmfs power_systems queue_depth 2 Comentários 34.228 Visualizações
At the IBM Power Systems Technical University in October, there was a fascinating session on Disk IO Tuning in AIX 6.1. I didn't get to see the session, but the presentation slides are well worth reading. (URL to the slides updated, Jan 24, 2017).
Even if you're not running 6.1, the principles and examples will be relevant.
Shows the percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.
We frequently think that a high I/O wait means the disk is maxing out, and a low iowait means your disk subsystem is performing fine, but it aint necessarily so. As the presentation slides explain (slide 10):
What is %iowait?
I've seen that last one, and it was a little hard to explain that the disks were running slowly, even though they were not completely busy.
mount -o log=NULL <file system>
I used that one recently to copy data from a software-striped file system to one without striping. I couldn't mirror to the new disks as the mklvcopy command would have wanted to retain the stripe set. The speed of copying to the no-log file system was remarkable, and as I had the original file system with a normal INLINE log, a system crash would have meant I'd still have the data on the original file system, but would have to start the copy again. It was worth the risk.
rmfs -r /somedir_old
To stash away for the AIX trivia night tie breaker
AnthonyEnglish 270000RKFN Marcações:  crfs jfs volume mkfs lv logical jfs2 system snapshot mount chfs journaled file performance inline cio enhanced 8 Comentários 40.760 Visualizações
Often in SMIT you can use the default settings, but when it comes to creating Enhanced Journalled File Systems – better known as JFS2 – there are three options which you’ll probably want to change from the defaults.
Of course you need to set the MOUNT POINT, but the other three I like to change are:
Here are the entries I change from the default when I create an enhanced Journalled File System using SMIT:
Mount automatically on system restart?
Ever find a new file system has gone missing after a reboot? You might have forgotten to change the automatic mount setting to yes when you created the file system. If you do set it to yes, the "mount" option will be set to true, as you can see from this in /etc/filesystems:
Any file systems with the mount option set to true will attempt to be mounted when you run either:
INLINE JFS2 Log
Setting the Logical Volume for Log attribute to INLINE means the JFS2 log is contained within the logical volume itself. This obviously helps avoid contention with other file systems, which would happen if they were all sharing the same JFS2log.
The oft-quoted Chris Gibson has yet another great article. This one's on JFS2 snapshots. As Chris explains, they allow you to create consistent, integrated snapshots of an online (or offline) JFS2 file system, in other words rapid, point-in-time copies which take up very little disk space. Even if I don't use them, when I create a JFS2 file system these days, from now on the "Allow internal snapshots" gets the tick (or, rather, the Tab).
Those last two options - INLINE logs and JFS2 snapshots - need to be set at the time of creating the file system. You can't changed either of them on an existing file system.
Mount options: CIO
For performance of Oracle databases, the file systems containing the database, control files and redo logs can be mounted using Concurrent I/O. The mount option is cio, but unlike the two previous settings (snapshots and INLINE logs), cio can be changed on an existing file system for its next mount. The CIO option takes effect when you mount the file system, so changing it requires unmounting and remounting for you to get the benefits of CIO. Turning it on ought to lead to a significant reduction in the use of paging space.
AnthonyEnglish 270000RKFN Marcações:  mount_point mksysb logical_volume lv importvg chfs volume_group chlv rootvg gentleman exclude.rootvg exportvg tsm aix manners file_system 19.728 Visualizações
Diamond in the SAN
I recently cloned an LPAR from a P6 to a less-busy P5 server via a mksysb backup. Unfortunately, after starting up the new LPAR I found that there was an essential directory missing because it had been excluded via the /etc/exclude.rootvg file (-e option on mksysb). Let's call the directory /diamond (its name has been changed to protect the guilty who didn't back it up).
I considered my options but each of them had a drawback.
Option 1: restore directory contents from TSM
I went with option 4, which allowed me to dig out the treasured directory's contents from the SAN. It did have the drawback that it would rename logical volumes on the original SAN LUN. I was willing to take the risk. It wasn't likely I would need to boot off that LUN again. Even if I did have to, I could always rename them via SMS in single user mode before mounting file systems.
I had to get the old rootvg onto a live AIX LPAR. Here's how I did it.
An import-ant command
After mapping the old SAN LUN to the new AIX LPAR, I used importvg to import the old LPAR's rootvg under another name - oldrootvg
newhost:/ # importvg -y oldrootvg hdisk3I got some warnings which I had to deal with before getting access to the contents of the directory I needed. The first was to do with LV names, the second was mount points. Here are the details,
LVM's good manners
When you're importing a rootvg (under a different name) onto a running LPAR with its own active rootvg, there are bound to be duplicate file systems and logical volumes. Fortunately, the AIX Logical Volume Manager (LVM) shows a bit of respect - the active LPAR's file systems and LVs don't get overwritten. The new guest LUN isn't allowed to push in. Instead, if there any conflicts, the imported VG gets new LV names. So when I ran importvg, hd4 was renamed to fslv02:
0516-530 synclvodm: Logical volume name hd4 changed to fslv02.
0516-530 synclvodm: Logical volume name hd2 changed to fslv03.
0516-530 synclvodm: Logical volume name hd9var changed to fslv04.
0516-530 synclvodm: Logical volume name hd3 changed to fslv05.
0516-530 synclvodm: Logical volume name hd1 changed to fslv06.
0516-530 synclvodm: Logical volume name hd10opt changed to fslv07.
Here's where the LVM showed itself to be a perfect gentleman. Good guests don't push people out of their own homes.
As for file systems, I got a warning about duplicate mount points that needed to be fixed before mounting the old rootvg's file systems:
imfs: Warning: mount point / already exists in /etc/filesystems.The logical volume for the file system I needed had been renamed from hd4 to fslv02, but the mount point was still set to /, so I had to change that for the newly named logical volume:
imfs: Warning: mount point /usr already exists in /etc/filesystems.
imfs: Warning: mount point /var already exists in /etc/filesystems.
imfs: Warning: mount point /tmp already exists in /etc/filesystems.
imfs: Warning: mount point /home already exists in /etc/filesystems.
imfs: Warning: mount point /opt already exists in /etc/filesystems.
chlv -L'/mnt/oldroot' fslv02At this point I created a new jfs2 log in smit lv (type jfs2log). I then set the jfs2log for my "new" root file system:
chfs -a log=/dev/loglv02 /mnt/oldroot
Finding that mount
The mount point /mnt/oldroot didn't exist, so I created the directory.
mkdir -p /mnt/oldrootI could then mount the file system /mnt/oldroot, and recover the contents of /mnt/oldroot/diamond.
I then cleaned up the oldrootvg using umount, varyoffvg and exportvg and rmdev of the disk. I then unmapped the SAN LUN which was no longer needed on the new host and was able to start the database.
I fixed the /etc/exclude.rootvg (and the TSM inclexcl file, just to be safe) and gave a quiet thanks that when importing the rootvg into an existing running LPAR, the LVM had acted as a perfect gentleman.
AnthonyEnglish 270000RKFN Marcações:  system decrease jfs2 disk nanoseconds guru chfs gigabyte lv space logical_volume increase aix jfs precious block_size file 8 Comentários 44.916 Visualizações
YOUR TIME IS PRECIOUS!
charge your time by the nanosecond!
Option 1: Specify new size of file system in blocks
chfs -a size=54132736 /oracle/staging
This, of course requires you to do a calculation or a guestimate of how many blocks the file system should be.
Option 2: Specify new size of file system in Gigabytes
That's easier, isn't it?
Option 3: Specify amount to increase file system in Gigabytes
This increases the file system by 4 GB.
You can reduce it - provided you have sufficient working space - using the -= (minus equals)
Option 4: Reduce file system by 500 Megabytes
Update: this originally showed the command operators as += instead of =-
Space and time
Or, you could just use SMIT. Sure, it will take a few seconds more, but you've got the time, haven't you?
AnthonyEnglish 270000RKFN Marcações:  file_systems delivering_baby chfs logical_volume_manager paging_space obstetrics_down_under volume_group multibos dump_devices size rootvg lvm aix 16.000 Visualizações
TRACING YOUR ROOTS
Every AIX system has a
volume group (a logical group of disks) called rootvg, which is created automatically at
the time you install AIX. The rootvg may be made up of one or several physical disks or virtual disks (SAN LUNs, Logical volumes on the VIO Server). Whatever "disks" make up rootvg, it's
important to keep the rootvg file system footprint small, but give the total disk assigned to rootvg enough
space to take giant steps. Let me explain.
After you've done an initial base AIX install, it's usually best to create your own new logical volumes and file systems in a separate volume group from rootvg, provided you've got the disk available. A separate data volume group (datavg) is better, unless your data and application file systems (and LVs) are relatively small.
It's important to keep your rootvg fairly lean.
That will speed up mksysb backups, recovery of the operating system,
migrations to new releases or cloning systems. Even though those upgrade and recovery activities are fairly rare, when they do happen you want to lose as little time as possible.
So the rule I (generally) follow is: rootvg for the OS, data file systems in their own volume group(s).
… large steps
Although it's sensible to keep your non-AIX data away from rootvg, it's even more important to be able to have lots of unused space within rootvg or the ability to increase disk allocation to rootvg quickly. Among other things, it's handy to have some head room in rootvg for:
Digging around the rootvg
To check how much available space you have in rootvg, use the lsvg command and run lsvg rootvg. Look at Free PPs to see how much rootvg disk is available for expansion.
Increase rootvg dynamically
If your rootvg “disk” is actually virtual, such as a SAN LUN or a logical volume on the VIO server, then it usually can be expanded on the SAN (or using extendlv on the VIOS) and then recognised on the AIX LPAR using the -g flag of the chvg command:
That "brief" introduction was a high level view of why rootvg can be hungry for disk. The rest is details, so you can
STOP READING NOW!
Unless you want a little more explanation on those steps above or are curious about something you won't find in a Redbook.
STEP BY STEP
File system growth
This should be obvious enough. If you
keep your apps and data in datavg or other volume groups, rootvg
should remain fairly stable. The /usr file system may even be sitting
at 98% and only get increased automatically when you install software
using AIX utilities such as smitty
or installp. Still, it's good to have some room for log files and temporary files. With disk space, prevention is better than cure.
Shrinking file systems
On recent releases of AIX, reducing a file system can be done using chfs without unmounting it. For example, this command will reduce /usr by 10 GB:
You need to have enough wriggle room to do this, though, so that's where the Free PPs are important.
AIX patching and installing new software
When you install patches such as AIX fix packs from the IBM Support Portal, you can either Apply or Commit the software updates. If you apply them, you can reject them, effectively rolling them back. Applying (rather than committing) software updates is a smart interim measure, but it does take a little more space. You'll obviously also need some room for when you install other software that gets written into the rootvg file systems.
System dump devices
System updates with multibos
If you haven't realised how easily you can have a dual boot on the same disk using multibos, you really are missing out on a very simple way of patching AIX while minimising downtime. My compatriot Chris Gibson has two excellent articles on AIX Updates with Multibos and Working With multibos. Easy to learn, and worth knowing, and in some ways an easier alternative to cloning the entire rootvg using alt_disk_install.
Nothing can bring an AIX system to its
knees as effectively as running out of paging space. Although paging
space (swap space) doesn't have to be in the rootvg, it's always
worth having some room for expansion of paging space. You will need
to reassess your paging space requirements if you increase your
memory allocation using Dynamic
LPAR or Changing
a partition profile's properties.
The mksysb command can do a backup of the rootvg by writing it to a file. Similarly, the mkcd and mkdvd commands back up the rootvg, but they need to create temporary file systems first. You can use flags to indicate an alternate volume group to use, but if you don't, then guess which one needs the extra space?
Learning more about LVM
If you want to learn more about LVM, have a look at a Wiki by the indefatigable Nigel Griffiths, where he deals with LVM theory and practice.
Not in the Redbooks
If you got this far, congratulations. Since you've obviously got nothing better to do with your time, let me explain why I couldn't resist including a graphic of baby feet.
I delivered a baby for the first time on Friday (you won't find a Redbook on that) after standing by over the years for the births of our five other children. Couldn't have done it without my wife. An obstetrician was there. He suggested I add "delivering babies" to the hobbies section of my resume.