Re: [gentoo-user] New Gentoo box

[Marc Joliet]

On Sunday 08 November 2015 10:55:19 J. Roeleveld wrote:
[...]
>For real comparisons, you need to stick both in the same box.
>The low results for the SSD are because of the lower-spec hardware of the
>rest of the system.
>Speed is always determined by the slowest part. In this case, the difference
>is very noticable.
>
>Put the SSD into the AMD-box and you'll see the true performance of the SSD.
>
>--
>Joost

One thing I'd like to add that I didn't see mentioned: even if the sequential 
read performance were worse, the thing that really sets SSDs apart is their 
*random* read and write performance, since they don't have to seek.  This is 
what makes them "feel" fast in everyday use.

HTH
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Bind stole my /

[Mike Gilbert]

On Fri, Nov 6, 2015 at 12:19 PM, Jarry  wrote:
> Hi Gentoo-users,
>
> I noted one strange thing today: It seems one of my servers lost "/"!
>
> vs5-dns ~ # df
> Filesystem1K-blocksUsed Available Use% Mounted on
> /var/log/named 10138552 2223148   7377344  24% /chroot/dns/var/log/named
> tmpfs308196 420307776   1% /run
> dev   10240   0 10240   0% /dev
> shm 1540968   0   1540968   0% /dev/shm
> cgroup_root   10240   0 10240   0% /sys/fs/cgroup
> none1048576   0   1048576   0% /var/tmp/portage
>
> And it seems I found the thief who stole it:
>
> vs5-dns ~ # /etc/init.d/named stop
>  * Caching service dependencies ...[ ok ]
>  * Stopping chrooted named ...
>  * Umounting chroot dirs ...
>  * umounting /chroot/dns/etc/bind ...  [ ok ]
>  * umounting /chroot/dns/var/log/named ... [ ok ]
>  * umounting /chroot/dns/var/bind ...  [ ok ]
> vs5-dns ~ # df
> Filesystem1K-blocksUsed Available Use% Mounted on
> /dev/sda2  10138552 2223140   7377352  24% /
> tmpfs308196 416307780   1% /run
> dev   10240   0 10240   0% /dev
> shm 1540968   0   1540968   0% /dev/shm
> cgroup_root   10240   0 10240   0% /sys/fs/cgroup
> none1048576   0   1048576   0% /var/tmp/portage
> vs5-dns ~ # /etc/init.d/named start
>  * Starting chrooted named ...
>  * Mounting chroot dirs
>  * mounting /etc/bind to /chroot/dns/etc/bind   [ ok ]
>  * mounting /var/bind to /chroot/dns/var/bind   [ ok ]
>  * mounting /var/log/named to /chroot/dns/var/log/named [ ok ]
>  * Checking named configuration ... [ ok ]
> vs5-dns ~ # df
> Filesystem1K-blocksUsed Available Use% Mounted on
> /var/log/named 10138552 2223160   7377332  24% /chroot/dns/var/log/named
> tmpfs308196 420307776   1% /run
> dev   10240   0 10240   0% /dev
> shm 1540968   0   1540968   0% /dev/shm
> cgroup_root   10240   0 10240   0% /sys/fs/cgroup
> none1048576   0   1048576   0% /var/tmp/portage
> vs5-dns ~ #
>
> So it seems whenever chrooted bind/named is running, "/" simply
> dissapeares from the list of mounted filesystem. Instead of it,
> chrooted /var/log/named is listed. Is this correct behaviour???
>
> This is a little problem for me, as I run monitoring software
> which (appart from other things) check filesystems if they are
> not close to being full. With bind/named running it complains
> it can not find "/" in df output. I'd like to get my "/" back,
> but I do not know how to do it...

Is your /etc/mtab a regular file, or is it a symlink to
/proc/self/mounts? The latter is recommended.

Anyway, please have a look at the contents of /etc/mtab,
/proc/self/mounts, and proc/self/mountinfo while named is running and
when it is stopped. If you pastebin them we can take a look for key
differences.

openrc questions (Re: [gentoo-user] pppoe questions)

[lee]

Alon Bar-Lev  writes:

> On 7 November 2015 at 20:21, lee  wrote:
>> Alon Bar-Lev  writes:
>>
 How does pppoe work together with shorewall and bind?

 When I stop the net.ppp0 service, shorewall is automatically stopped as
 well.  When I start net.ppp0, shorewall is not started automatically.

 I would like to automatically have net.ppp0 first started and then
 shorewall.
>>>
>>> usually the firewall service should be started before all interfaces
>>> (except lo).
>>> add the following to /etc/conf.d/net.ppp0:
>>> ---
>>> rc_net_ppp0_need="firewall net.enp2s0"
>>> ---
>>
>> Thanks!  I copied net.lo to net.ppp0 and put it at the top so it now
>> goes:
>>
>>
>> #!/sbin/runscript
>> # Copyright (c) 2007-2009 Roy Marples 
>> # Released under the 2-clause BSD license.
>>
>> MODULESDIR="/lib/netifrc/net"
>> MODULESLIST="${RC_SVCDIR}/nettree"
>> _config_vars="config routes"
>
> you do not need these^

They were already there, so I'll leave them.

>> rc_net_ppp0_need="firewall net.enp2s0"
>>
>
> you do need ^

I took it out because when shorewall is started before ppp0 is up,
shorewall says it can't do things with ppp0.  So I think ppp0 needs to
be up for shorewall to work right and things have to be started in an
undesirable order (unless perhaps I would restart shorewall when ppp0 is
up).

What's the right way of handling this?

>> I'm not sure if that's right --- I guess I shouldn't make a copy?
>
> correct :)

ok

>>> this will make sure that the ppp0 interface is started after both
>>> firewall and enp2s0.
>>>
>>> I also have the following in /etc/rc.conf to avoid stopping services
>>> while network is down:
>>> ---
>>> rc_hotplug="!net.enp2s0 !net.ppp*"
>>> ---
>>
>> The comment in /etc/rc.conf says no hotplugging is done by default.
>> IIUC, you are hotplugging 'net.enp2s0' and 'net.ppp*'?  So allowing to
>> hotplug them would kinda make them independent of other services, or
>> other services independent from them?
>
> no... the opposite, we do not want to be effected (! == not) by
> hotplug of these devices.

The description of this option says:

,
| # rc_hotplug is a list of services that we allow to be hotplugged.
| # By default we do not allow hotplugging.
| # A hotplugged service is one started by a dynamic dev manager when a matching
| # hardware device is found.
| # This service is intrinsically included in the boot runlevel.
| # To disable services, prefix with a !
| # Example - rc_hotplug="net.wlan !net.*"
| # This allows net.wlan and any service not matching net.* to be plugged.
| # Example - rc_hotplug="*"
| # This allows all services to be hotplugged
| #rc_hotplug="*"
`

With 'rc_hotplug="!net.enp2s0 !net.ppp*"', you would:


[1] forbid 'net.enp2s0' to be hotplugged and
[2] allow all services that do not match 'net.ppp*' to be hotplugged.


[1] is not necessary because nothing can be hotplugged by default.
[2] is very likely /not/ what you want --- or why would you want this.


Aside from this, what exactly happens when you allow a service to be
hotplugged?  Is this service never started by openrc because openrc
figures that the service is started otherwise (like by a device
manager)?  What does it do about services that depend on a service that
can be hotplugged?


And yet another question:

Does rc-update, or something else, monitor the scripts in /etc/init.d?
When I remove a script, or a link to one, from there, 'rc-update show'
doesn't show the removed script anymore, and it cannot be deleted from
its runlevel.

Re: [gentoo-user] New Gentoo box

[J. Roeleveld]

On Saturday, November 07, 2015 03:06:32 PM the...@sys-concept.com wrote:
> On 11/07/2015 02:52 PM, Bill Kenworthy wrote:
> > On 08/11/15 05:22, the...@sys-concept.com wrote:
> >> On 11/05/2015 11:06 PM, J. Roeleveld wrote:
> >> [snip]
> >> 
>  You might be right, maybe I'll add one HDD for backup (good
>  suggestion).
>  The killer is my 1TB SSD $499.99CAD
> >>> 
> >>> Get 1 SSD for the OS, software and your home directory. (240GB is
> >>> usually
> >>> enough)
> >>> And 1 big HDD for your data.
> >>> 
> >>> Keep your documents and other data out of the home directory if doing
> >>> this.
> >>> Reason I suggest your home directory on SSD is because programs tend to
> >>> store a lot in your home directory which can benefit from a faster
> >>> disk.>> 
> >> It seems to me that SSD drives are slower than standard spinning disks.
> >> I was just comparing my two disk with hdparm
> >> 
> >> 1.) Western Digital model:  Model=WDC WD2002FAEX-007BA0
> >> 
> >>  hdparm -Tt /dev/sda
> >> 
> >> /dev/sda:
> >>  Timing cached reads:   9406 MB in  2.00 seconds = 4705.88 MB/sec
> >>  Timing buffered disk reads: 432 MB in  3.00 seconds = 143.92 MB/sec
> >> 
> >> 2.) Intel SSD model Model=INTEL SSDSC2BF480A5
> >> 
> >> /dev/sda:
> >>  Timing cached reads:   1292 MB in  2.00 seconds = 645.51 MB/sec
> >>  Timing buffered disk reads: 536 MB in  3.00 seconds = 178.63 MB/sec
> >> 
> >> It seems to me the spinning disk WD is faster than my Intel SSD
> >> So is there an advantage of overpaying for SSD?
> >> 
> >> --
> >> Thelma
> > 
> > olympus ~ # hdparm -tT /dev/sda
> > 
> > /dev/sda:
> >  Timing cached reads:   20442 MB in  1.99 seconds = 10278.90 MB/sec
> >  Timing buffered disk reads: 1164 MB in  3.00 seconds = 387.66 MB/sec
> > 
> > olympus ~ # hdparm -tT /dev/sdb
> > 
> > /dev/sdb:
> >  Timing cached reads:   20320 MB in  1.99 seconds = 10218.13 MB/sec
> >  Timing buffered disk reads: 300 MB in  3.00 seconds =  99.88 MB/sec
> > 
> > olympus ~ #
> > 
> > 
> > Something is not right with your system ...
> > 
> > sda is an older intel ssd, sdb is a western digital red which somethimes
> > gets close to that your speed.
> > 
> > try multiple measurements, no load on the system.
> 
> I did run test several times, still get the same numbers. Maybe the
> reason is that one system is much smaller slower.
> 
> The SSD is running on smaller box: Atom-TM-_CPU_330_@_1.60GHz
> The WD is bitter unit: AMD_FX-tm-8150_Eight-Core_Processor

For real comparisons, you need to stick both in the same box.
The low results for the SSD are because of the lower-spec hardware of the rest 
of the system.
Speed is always determined by the slowest part. In this case, the difference is 
very noticable.

Put the SSD into the AMD-box and you'll see the true performance of the SSD.

--
Joost

Re: [gentoo-user] Portage cleaning up 32bit preserved libs (x86_64/amd64)

[Mick]

On Saturday 07 Nov 2015 18:19:22 bitlord wrote:

> # emerge @preserved-rebuild
> which did nothing, so currently I don't need those libs, and don't know
> what is a proper way to get rid of them.

You should also run 'revdep-rebuild -p' which may catch something that 'emerge 
@preserved-rebuild' missed.


> Here is the list:
> app-arch/bzip2-1.0.6-r6 /usr/lib32/libbz2.so.1.0.6 /usr/lib32/libbz2.so.1
> dev-libs/glib-2.44.1 /usr/lib32/libglib-2.0.so.0.4400.1
> /usr/lib32/libglib-2.0.so.0 media-gfx/graphite2-1.2.4-r1
> /usr/lib32/libgraphite2.so.3.0.1 /usr/lib32/libgraphite2.so.3
> media-libs/freetype-2.5.5 /usr/lib32/libfreetype.so.6.11.4
> /usr/lib32/libfreetype.so.6 media-libs/harfbuzz-0.9.41
> /usr/lib32/libharfbuzz.so.0.941.0 /usr/lib32/libharfbuzz.so.0
> media-libs/libpng-1.6.18 /usr/lib32/libpng16.so.16.18.0
> /usr/lib32/libpng16.so.16 sys-libs/zlib-1.2.8-r1 /lib32/libz.so.1.2.8
> /lib32/libz.so.1

You could unmerge each one of them and then run 'emerge -uatDv world' and/or 
rerun 'emerge @preserved-rebuild', which will rebuild any libraries portage 
thinks your system needs.  The former will show you what is pulling them in.

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.