Thought I'd share, since this isn't in any documentation or TID that I
can find.

Before you move to OES2 Linux with NSS or multipathing code or EVMS, you
may want to consider this limitation (IMO, a major limitation if you're
running an Enterprise).

If you SAN allows you to grow/expand a LUN (ie, LUN1 was 50 GB and now
you grow it to 100 GB), you cannot use the new space until you reboot
the server itself. If you're running NCS, then you need to reboot every
node that can host the clustered resource before you can expand the NSS

The issue is a bug in the devmapper portion of SLES. ANYTHING that uses
devmapper will prevent the further layers (ie, multipathing or EVMS)
from seeing the additional space until you reboot the server.

Obviously rebooting servers in the middle of the day to add more space
affects Enterprise services to your users. As does making them wait
until off-hours before they can write/save any data to the servers. Not
to mention rebooting multiple nodes in your NCS cluster.

Novell won't fix this until SLES 11. Even then (ie, if you implement
OES2 now and can live with the limitation it won't be truly fixed in
SLES 11 if you're using NSS/EVMS), as the limitation will still be in
EVMS in SLES 11. Therefore, you'd have to migrate your data to LVM2 (I
believe that's what Novell is switching to). Yet another major
disruption for your users.

So, if you're thinking about OES2 with NSS/EVMS or multipathing, you may
want to consider the effect this will have to your userbase (ie, how
many times do you want to migrate your data?)

In our case, looks like it's goint to be one migration --- to MS