I'm working through the 6.2 bugzillas.  Right now there are no features requests that require documentation.  Some of the bugzillas will likely require a new feature to fix them, which will need documentating.

Right now the only bug that does this is 631009.

multipath and kpartx now have a -u option that will force the udev dm-disk
rules to be run for reloads of existing devices. However, this should never
be used by the user under normal circumstances.  It's only intended for rc.sysinit.  I'm not sure what the documentation policy is for things like this.

The only other documentation change for RHEL 6.2 is for 710478. the uid, gid, and mode, multipath.conf parameters have been depricated, since udev now controls this functionality.  Multipath will not flag them as invalid parameters, but they won't do anything anymore.

*** Bug 713195 has been marked as a duplicate of this bug. ***

For info's sake, I'm noting this comment from BZ#710478, written by Peter Rajnoha. I will check on whether I need to document that udev rules are now used for permissions, and whether to document this template file.

-------
Yes, permissions for device-mapper devices (including multipath mappings) is
set via udev rules now. Once udev is used, we can't change the permissions that
udev daemon sets based on udev rules - we would need to switch udev support off
to fallback to old way of creating the nodes. Setting permissions using udev
rules is the only correct way in this situation.

There's a template file in /usr/share/doc/device-mapper-<version> called
12-dm-permissions.rules which you can use and place in /etc/udev/rules.d
directory for it to take effect.

Please, consider using this template and if you have any problems, feel free to
report or ask for support. Thanks.

-----------
multipath and kpartx now have a -u option that will force the udev dm-disk
rules to be run for reloads of existing devices. However, this should never
be used by the user under normal circumstances.  It's only intended for
rc.sysinit.  I'm not sure what the documentation policy is for things like
this.
----------

It doesn't seem to fall under the rubric of system administration -- my sense is that this is what I think of as internal. But if you think there's a need for me to document it I can consider adding a section on udev rules to the administration chapter, nothing both this and the template file in /usr/share/doc/device-mapper-<version>.

No I don't see a need to document the -u option. It's only for use during bootup.

Multipath now autoconfigures the IBM 1820N00

There is now a new multipath.conf parameter, rr_min_io_rq, in the defaults, devices and multipaths section of multipath.conf.  rr_min_io no longer does
anything in rhel6.  It is only for older kernels.

#       #
#       # name    : rr_min_io
#       # scope   : multipath
#       # desc    : the number of IO to route to a path before switching
#       #           to the next in the same path group. This setting is only
#       #           for systems running kernels older that 2.6.31. Newer
#       #           systems should use rr_min_io_rq.
#       # default : 1000
#       #
#       rr_min_io       100
#
#       #
#       # name    : rr_min_io_rq
#       # scope   : multipath
#       # desc    : The number of IO to route to a path before switching to
#       #           the next in the same path group, using request-based
#       #           device-mapper-multipath. This setting should be used on
#       #           systems running current kernels. On systems running kernels
#       #           older than 2.6.31, use rr_min_io.
#       # default : 1

Also dev_loss_tmo can now be set to infinity, which sets the actual sysfs variable to 2147483647 seconds, or 68 years.

#       #
#       # name    : dev_loss_tmo
#       # scope   : multipath & multipathd
#       # desc    : The number of seconds the scsi layer will wait after a
#       #           problem has been detected on a FC remote port before
#       #           removing it from the system. Setting this to infinity
#       #           will set this to 2147483647 seconds, or 68 years.
#       # values  : n > 0 | infinity
#       # default : determined by the OS
#       dev_loss_tmo 600

When Ben OKs (or reviews) my writeup of the new information I will move this Bug to MODIFIED.