Re: How to keep multiple glibc release instances in use

[Tom H]

On Thu, Jul 10, 2014 at 8:39 AM, Lamar Owen  wrote:
> On 07/09/2014 08:48 PM, Nico Kadel-Garcia wrote:
>>
>> The other dirty trick would be to use something like 'mock' to build a
>> chroot cage, and put your tools inside the chroot cage. ...
>
> I have to wonder if the 'Software Collections' framework could work for
> glibc.  Otherwise your solution should work ok, even though it is more than
> a bit of a kluge.

Or use lxc on EL6 or lxc or systemd-nspawn on EL7.

Re: How do you speed up rsync?

[Joseph Areeda]

Just to add another/different option.

I had a good 760G 2.5" hard drive left over when I upgraded my laptop to 
SSD.  For less $20 I bought a USB3 case for it.  It runs at aboutt SATA 
speeds and needs no other power.

While bigger than a USB stick it's still small enough for my backpack.

Joe

On 07/11/2014 10:44 PM, Steven Haigh wrote:

On 12/07/2014 3:24 PM, ToddAndMargo wrote:

On 07/11/2014 01:49 PM, Patrick J. LoPresti wrote:

On Fri, Jul 11, 2014 at 1:40 PM, Patrick J. LoPresti
 wrote:

Try giving the "--size-only" option to rsync.

Better yet, try "--modify-window=1". From the rsync man page:

--modify-window
When  comparing  two  timestamps, rsync treats the
timestamps as
being equal if they differ by no  more  than  the
modify-window
value.   This  is  normally  0 (for an exact match),
but you may
find it useful to set this to a larger value in some
situations.
In  particular,  when  transferring to or from an MS
Windows FAT
filesystem (which represents times with a 2-second
resolution),
--modify-window=1 is useful (allowing times to differ
by up to 1
second).


   - Pat


Hi Pat,

--modify-window=1
   3 hr - 9 sec

--modify-window=10
   3 hr - 8 sec

Rat!  I really though this sounded right


I did notice that the bugger the file (with no changes)
the longer it took.  So, I think they are still doing
check sums.

Any way to turn of the check sum testing?

Now you're starting to get off task... How can you sync something if you
don't know if it matches? Sure, you can only go off timestamps - but
what then? It leaves you with a situation where you may get files that
are different and you'll never know.

You'd be much better off getting a better flash drive (ie not add hack
upon hack that may not help) and fixing the root cause of the problem.

Hell, get a small laptop HDD and put it in a USB caddy case. Get a small
SSD (they're cheap!) and put that in a case...

Re: How to keep multiple glibc release instances in use

[Yasha Karant]

On 07/12/2014 05:27 AM, Tom H wrote:

On Thu, Jul 10, 2014 at 8:39 AM, Lamar Owen  wrote:

On 07/09/2014 08:48 PM, Nico Kadel-Garcia wrote:

The other dirty trick would be to use something like 'mock' to build a
chroot cage, and put your tools inside the chroot cage. ...

I have to wonder if the 'Software Collections' framework could work for
glibc.  Otherwise your solution should work ok, even though it is more than
a bit of a kluge.

Or use lxc on EL6 or lxc or systemd-nspawn on EL7.

From:

http://en.wikipedia.org/wiki/Lxc

LXC is similar to other OS-level virtualization technologies on Linux 
such as OpenVZ  and Linux-VServer 
, as well as those on other 
operating systems such as FreeBSD jails 
, AIX 
 Workload Partitions 
 and Solaris 
Containers . In 
contrast to OpenVZ, LXC works in the vanilla Linux kernel 
 requiring no 
additional patches to be applied to the kernel sources. Version 1 of the 
LXC, which was released on 20 February 2014, is a long-term supported 
version and intended to be supported for five years.^[6] 



End quote.

The above -- if it works and does not require "excessive" system 
resources would be the solution we need, as it has something akin to 
real polymorphism.  Does it have something akin to inheritance, using 
all of the base (native) environment except as needed to avoid 
inconsistencies?  Can one load, say, the appropriate glibc within a LXC 
container without loading what is tantamount to a full OS environment?


Any comments from actual users of LXC or any competitors/alternatives 
thereto?\


I am in the field today, and in a time constrained situation, and thus 
no time to hunt -- are any of these available via RPMs in a production 
release with some sort of built-in configuration tool(s)?


Yasha Karant

Re: How do you speed up rsync?

[ToddAndMargo]

On 07/11/2014 10:56 PM, Steven Haigh wrote:

On 12/07/2014 3:49 PM, ToddAndMargo wrote:

On 07/11/2014 10:44 PM, Steven Haigh wrote:

On 12/07/2014 3:24 PM, ToddAndMargo wrote:

On 07/11/2014 01:49 PM, Patrick J. LoPresti wrote:

On Fri, Jul 11, 2014 at 1:40 PM, Patrick J. LoPresti
 wrote:


Try giving the "--size-only" option to rsync.


Better yet, try "--modify-window=1". From the rsync man page:

--modify-window
 When  comparing  two  timestamps, rsync treats the
timestamps as
 being equal if they differ by no  more  than  the
modify-window
 value.   This  is  normally  0 (for an exact match),
but you may
 find it useful to set this to a larger value in some
situations.
 In  particular,  when  transferring to or from an MS
Windows FAT
 filesystem (which represents times with a 2-second
resolution),
 --modify-window=1 is useful (allowing times to differ
by up to 1
 second).


- Pat



Hi Pat,

--modify-window=1
3 hr - 9 sec

--modify-window=10
3 hr - 8 sec

Rat!  I really though this sounded right


I did notice that the bugger the file (with no changes)
the longer it took.  So, I think they are still doing
check sums.

Any way to turn of the check sum testing?


Now you're starting to get off task... How can you sync something if you
don't know if it matches? Sure, you can only go off timestamps


How would I do size and time stamp?

Virtually everything I modify will either be a different size
and/or get a new time stamp.  I can not think of a reason
why, in this instance, I'd need to do a check sum.


Then you don't want to use rsync - as you're not syncing. rsync will
also checksum data AFTER copying to verify the copy was successful.

If you don't care about the rest, try the normal cp:
cp -apu /path/to/source /path/to/destination




One of the things I like about rsync is that I can
get rid of the defunct stuff on the stick.  I suppose
I could write a subroutine (function I think they call
it in bash) to do that before cutting loose the cp

--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~