[linux-lvm] LVM2 configure options for CLVM with GFS

[linux-lvm] LVM2 configure options for CLVM with GFS

[Ed L Cashin]

Hi.  The example at ...

  http://gfs.wikidev.net/Installation

... shows this command line for LVM2 configuration:

  ./configure --with-clvmd --with-cluster=shared \
     --with-kernel-source=/path/to/patched/kernel

I see there are more options that look to me like they should be set
to "shared" for using CLVMD with GFS:

  --with-pool=TYPE        GFS pool read-only support: internal/shared/none
                          TYPE=internal
  --with-cluster=TYPE     Cluster LVM locking support: internal/shared/none
                          TYPE=internal
  --with-snapshots=TYPE   Snapshot support: internal/shared/none
                          TYPE=internal
  --with-mirrors=TYPE     Mirror support: internal/shared/none
                          TYPE=internal

If I'm already running the patched kernel that I plan to use, should I
configure LVM2 like this?

  ./configure --with-clvmd --with-cluster=shared \
    --with-pool=shared \
    --with-snapshots=shared \
    --with-mirrors=shared


-- 
  Ed L Cashin <ecashin@coraid.com>

[linux-lvm] Re: LVM2 configure options for CLVM with GFS

[Ed L Cashin]

Ed L Cashin <ecashin@coraid.com> writes:

...
>   --with-pool=TYPE        GFS pool read-only support: internal/shared/none
>                           TYPE=internal
>   --with-cluster=TYPE     Cluster LVM locking support: internal/shared/none
>                           TYPE=internal
>   --with-snapshots=TYPE   Snapshot support: internal/shared/none
>                           TYPE=internal
>   --with-mirrors=TYPE     Mirror support: internal/shared/none
>                           TYPE=internal

Alasdair pointed out to me in the IRC channel that these options do
not configure LVM's ability to share state with other nodes in the
cluster.  Rather, they simply choose how to link in the components of
the LVM binaries -- shared or static.

So it doesn't matter, and the example in GFS' usage.txt should work
fine. 

-- 
  Ed L Cashin <ecashin@coraid.com>