Re: [OpenIndiana-discuss] Odd Samba/winbind issue

2013-06-26 Thread Laurent Blume

On 25/06/13 18:15, James Relph wrote:



All the rest is good but that crle line - ugh.


Ignore that, I should have deleted it out.  I was using that while
trying to sort out the LDFLAGS bit, but it's not necessary.


Aha, good ;-)


One thing in terms of the LDFLAGS line actually that you might know
(I really don't compile stuff this complicated very often!) but I've
currently got:

-L/root/samba-4.0.6/bin/shared/private
-R/usr/local/samba/lib/private

In there.  The installation copies the contents of the
bin/shared/private folder in the installation directory to
/usr/local/samba/lib/private, so is that the correct method, or could
I have put -L/usr/local/samba/lib/private
-R/usr/local/samba/lib/private (ie. would the compiler have been
aware that that's where those libraries were destined for)?


To be honest, it looks a bit odd to me to have a private/ there, but 
I've not built Samba4 yet, so it's probably fine, and their way to show 
that some libs should not be linked against by others.
As for the linking: the -L bit is probably superfluous, but not hurtful. 
Most build scripts add automatically the needed relative path at link 
time, and often even relink when installing. The -R should be good as it is.


Laurent


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Odd Samba/winbind issue

2013-06-26 Thread Gary Mills
On Wed, Jun 26, 2013 at 10:25:53AM +0200, Laurent Blume wrote:
 On 25/06/13 18:15, James Relph wrote:
 
 In there.  The installation copies the contents of the
 bin/shared/private folder in the installation directory to
 /usr/local/samba/lib/private, so is that the correct method, or could
 I have put -L/usr/local/samba/lib/private
 -R/usr/local/samba/lib/private (ie. would the compiler have been
 aware that that's where those libraries were destined for)?
 
 To be honest, it looks a bit odd to me to have a private/ there, but
 I've not built Samba4 yet, so it's probably fine, and their way to
 show that some libs should not be linked against by others.
 As for the linking: the -L bit is probably superfluous, but not
 hurtful. Most build scripts add automatically the needed relative
 path at link time, and often even relink when installing. The -R
 should be good as it is.

There are other ways, but here's one way to see the runtime path
that's encoded in an executable:

$ dump -Lv /usr/sbin/gdm-binary | grep PATH
[30]RUNPATH /usr/lib:/usr/sfw/lib
[31]RPATH   /usr/lib:/usr/sfw/lib

This is a good check in case you can't tell what the build script
is doing.  You can also use `ldd' to see how the paths to shared
modules are resolved.

-- 
-Gary Mills--refurb--Winnipeg, Manitoba, Canada-

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


[OpenIndiana-discuss] Switching from lzjb to lz4 compression

2013-06-26 Thread Gary Gendel

Hi,

Can I switch from one algorithm to another on the fly?  I assume that 
only newly written data will be affected, but can the system deal with a 
mixed compression pool?


Gary


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Switching from lzjb to lz4 compression

2013-06-26 Thread Saso Kiselkov
On 26/06/2013 21:01, Gary Gendel wrote:
 Hi,
 
 Can I switch from one algorithm to another on the fly?  I assume that
 only newly written data will be affected, but can the system deal with a
 mixed compression pool?

See http://wiki.illumos.org/display/illumos/LZ4+Compression How To Use
It and LZ4 On Root Pools sections - that should explain what is
needed and what the implications are.

Cheers,
-- 
Saso

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Switching from lzjb to lz4 compression

2013-06-26 Thread Jim Klimov

On 2013-06-26 22:01, Gary Gendel wrote:

Hi,

Can I switch from one algorithm to another on the fly?  I assume that
only newly written data will be affected, but can the system deal with a
mixed compression pool?


I believe it should be same as other compression algorithms
(though may be more complicated due to use of feature flags).
It was generally true that compression, checksums, copies and
such write-time attributes are basically applied per-block at
the time of write (i.e. if you zfs-send an uncompressed dataset
and zfs-receive it into a compressed target dataset, the newly
written blocks will be compressed).

It is not a problem to have different algorithms (including
none/off values) to be mixed in a single dataset, and of
course quite possible to mix them in a pool.

Another matter is the rpool dataset - it should use those algos
which are added into GRUB support so it can mount the root.
I believe LZ4 is among these (for source code versions of the
illumos-gate which offer LZ4 integration altogether).

HTH,
//Jim Klimov


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Switching from lzjb to lz4 compression

2013-06-26 Thread Gary Gendel

On 06/26/2013 04:16 PM, Jim Klimov wrote:

On 2013-06-26 22:01, Gary Gendel wrote:

Hi,

Can I switch from one algorithm to another on the fly?  I assume that
only newly written data will be affected, but can the system deal with a
mixed compression pool?


I believe it should be same as other compression algorithms
(though may be more complicated due to use of feature flags).
It was generally true that compression, checksums, copies and
such write-time attributes are basically applied per-block at
the time of write (i.e. if you zfs-send an uncompressed dataset
and zfs-receive it into a compressed target dataset, the newly
written blocks will be compressed).

It is not a problem to have different algorithms (including
none/off values) to be mixed in a single dataset, and of
course quite possible to mix them in a pool.

Another matter is the rpool dataset - it should use those algos
which are added into GRUB support so it can mount the root.
I believe LZ4 is among these (for source code versions of the
illumos-gate which offer LZ4 integration altogether).

HTH,
//Jim Klimov

Jim,

Thanks.  That was what I thought based upon my recollection but I just 
couldn't find it documented.


Gary


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss