On Wed, 2010-03-03 at 23:42 +0100, Gianluca Cecchi wrote:
> On Wed, 03 Mar 2010 16:53:49 -0500, Lon Hohberger wrote:
> > As it happens, the 'fs' file system type looks for child 'fs'
> resources:
> >
> > <child type="fs" start="1" stop="3"/>
> >
> > ... but it does not have an entry for 'lvm', which would be required
> to
> > make it work in the order you specified.
>
> With this argument I understand expected behaviour now, even if not so
> intuitive imho
> Probably it's only me, but I did read the page referred in [1] and I
> didn't deduce what you write above...
It is not intuitive - and actually it's probably /broken/, because it's
inconsistent with the service agent.
It could be easily fixed with no adverse impact unless someone was
making LVM devices out of files which were on the on the file system
(via loopback)... which would be a very strange thing to do.
> In fact there are terms such as "type-specified children" and "untyped
> children"....
> In my case lvm is a type-specified child as I understood, so that I
> thought it should have started after the same level fs resource... not
> before it
It is but only as a direct descendant of <service>. :/
> Now,
> if passing from a running
> <service domain="MAIN" autostart="1" name="TESTSRV">
> <ip ref="10.4.5.157"/>
> <lvm ref="TEST_APPL"/>
> <fs ref="TEST_APPL"/>
> <lvm ref="TEST_DATA"/>
> <fs ref="TEST_DATA">
> <lvm ref="TEST_TEMP"/>
> <fs ref="TEST_TEMP"/>
> </fs>
> <script ref="clusterssh"/>
> </service>
>
> To your suggested
>
> <service domain="MAIN" autostart="1" name="TESTSRV">
> <ip ref="10.4.5.157"/>
> <lvm ref="TEST_APPL"/>
> <fs ref="TEST_APPL"/>
> <lvm ref="TEST_DATA"/>
> <lvm ref="TEST_TEMP"/>
> <fs ref="TEST_DATA">
> <fs ref="TEST_TEMP"/>
> </fs>
> <script ref="clusterssh"/>
> </service>
>
> will or will not disrupt service (such as umount/mount of the FS_TEMP
> filesystem)?
I think it will remount TEST_TEMP.
You can test:
Copy /etc/cluster.conf /tmp/cluster.conf.old
Copy /etc/cluster.conf /tmp/cluster.conf.new
Make changes to /tmp/cluster.conf.new
run:
rg_test delta /tmp/cluster.conf.old \
/tmp/cluster.conf.new &> /tmp/delta.out
In delta.out, you will see [NEEDSTOP] in the old resource tree and
[NEEDSTART] in the new resource tree. Those are the resources which are
stopped/started.
(Be sure to look at the resource trees, not the start/stop phases)
-- Lon
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
