From: Gordan B. <go...@bo...> - 2008-11-22 21:49:15
|
Marc Grimme wrote: > On Saturday 22 November 2008 16:51:31 Gordan Bobic wrote: >> Marc Grimme wrote: >>> But why not go this way: >>> There is a method/function "clusterfs_services_start" which itself calls >>> ${clutype}_services_start which should be implemented by >>> etc/${rootfs}-lib.sh. Your $rootfs should be glusterfs and therefore >>> there should be a library glusterfs-lib.sh. The function >>> clusterfs_services_start should do all the preparations to mount the >>> clusterfilesystem and could also mount a local filesystem as a >>> prerequisite. So I would put it there. A rootfs can be specified as >>> follows: >>> <rootvolume name="/dev/whicheverdeviceyoulike" fstype="glusterfs"/> >> OK, this solution wins on the grounds that remapping the chrootenv seems >> to confuse glusterfs. >> >> But ${clutype}_services_start is dependent on ${clutype}, which is >> returned from getCluType(), which always returns "gfs". Will that not >> break things? > > Not any more take the latest version of clusterfs-lib.sh and it is dependent > on rootfs. I changed it how it should recently. Do you mean you changed getCluType(), or made it irrelevant? I freshly rebuilt the test box this morning, that that's where getCluType() was always returning "gfs". Anyway, I'll just ignore it if it's not important. Gordan |