Re: [OpenIndiana-discuss] Odd Samba/winbind issue
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
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
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
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
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
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