Re: [gentoo-user] [Gentoo-User] emerge --sync likely to kill SSD?
On Thu, Jun 19, 2014 at 10:36:59AM +0800, microcai wrote: rsync is doing bunch of 4k ramdon IO when updateing portage tree, that will kill SSDs with much higher Write Amplification Factror. I have a 2year old SSDs that have reported Write Amplification Factor of 26. I think the only reason is that I put portage tree on this SSD to speed it up. what is the suggest way to reduce Write Amplification of a portage sync ? Maybe the only solution is that move the portage tree to HDD??
Re: [gentoo-user] [Gentoo-User] emerge --sync likely to kill SSD?
On Thu, 19 Jun 2014 16:40:08 +0800, Amankwah wrote: Maybe the only solution is that move the portage tree to HDD?? Or tmpfs if you rarely reboot or have a fast enough connection to your preferred portage mirror. -- Neil Bothwick The voices in my head may not be real, but they have some good ideas! signature.asc Description: PGP signature
Re: [gentoo-user] [Gentoo-User] emerge --sync likely to kill SSD?
On Thu, Jun 19, 2014 at 7:44 AM, Neil Bothwick n...@digimed.co.uk wrote: On Thu, 19 Jun 2014 16:40:08 +0800, Amankwah wrote: Maybe the only solution is that move the portage tree to HDD?? Or tmpfs if you rarely reboot or have a fast enough connection to your preferred portage mirror. There has been a proposal to move it to squashfs, which might potentially also help. The portage tree is 700M uncompressed, which seems like a bit much to just leave in RAM all the time. Mine is on an SSD, but the SMART attributes aren't well-documented so I have no idea what the erase count or WAF is - just the LBA written count. Rich
Re: [gentoo-user] [Gentoo-User] emerge --sync likely to kill SSD?
On 19/06/2014 12:56, Rich Freeman wrote: On Thu, Jun 19, 2014 at 7:44 AM, Neil Bothwick n...@digimed.co.uk wrote: On Thu, 19 Jun 2014 16:40:08 +0800, Amankwah wrote: Maybe the only solution is that move the portage tree to HDD?? Or tmpfs if you rarely reboot or have a fast enough connection to your preferred portage mirror. There has been a proposal to move it to squashfs, which might potentially also help. The portage tree is 700M uncompressed, which seems like a bit much to just leave in RAM all the time. The tree will not necessarily be left in RAM all of the time. Pages allocated by tmpfs reside in pagecache. Given sufficient pressure, they may be migrated to swap. Even then, zswap [1] could be used so as to reduce write amplification. I like Neil's suggestion, assuming that the need to reboot is infrequent. --Kerin [1] https://www.kernel.org/doc/Documentation/vm/zswap.txt
[gentoo-user] update world problem (looks like slot confusion on my part)
(I am in the months long process of converting from testing to stable, using the bothwick going stable method; but I don't believe that is related to the question I am asking.) I was away for several days and have a number of problem with my normally-daily update world. Some may be due to the testing--stable conversion but some I just don't understand at all. The first complaint is Conflict: 2 blocks (1 unsatisfied) !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-libs/openssl:0 (dev-libs/openssl-1.0.1h-r1::gentoo, installed) pulled in by (no parents that aren't satisfied by other packages in this slot) (dev-libs/openssl-1.0.1h-r2::gentoo, ebuild scheduled for merge) pulled in by =dev-libs/openssl-1.0.1h-r2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (net-nds/openldap-2.4.38-r2::gentoo, installed) I assume that the no parents that aren't satisfied ... means that portage could handle this one. There are a few more again with no parents Then comes one that I can't understand virtual/libintl:0 (virtual/libintl-0-r1::gentoo, ebuild scheduled for merge) pulled in by =virtual/libintl-0-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (net-libs/gnutls-3.3.4::gentoo, ebuild scheduled for merge) (virtual/libintl-0::gentoo, installed) pulled in by =virtual/libintl-0 required by (net-analyzer/nmap-6.25::gentoo, installed) (and 31 more with the same problem) This seems to say that nmap-6.25 requires specifically virtual/libintl-0. But I went to net-analyzer/nmap-6.25.ebuild and the only occurrence of libintl is nls? ( virtual/libintl ) in RDEPEND Why does this require specifically virtual/libintl-0 and not permit virtual/libintl-0-r1? Any help would be appreciated. allan
Re: [gentoo-user] update world problem (looks like slot confusion on my part)
On 19/06/2014 21:17, gottl...@nyu.edu wrote: (I am in the months long process of converting from testing to stable, using the bothwick going stable method; but I don't believe that is related to the question I am asking.) I was away for several days and have a number of problem with my normally-daily update world. Some may be due to the testing--stable conversion but some I just don't understand at all. First thing: I understand why you want to go testing - stable, but at least leave portage unstable. A *lot* of ancient stuff has been fixed in ~arch, it's perfectly safe and robust, and most especially all that stupid no parents that aren't satisfied by other packages in this slot has gone away, replaced with something that a) works and b) makes sense and c) does not reduce the poor sysadmin (i.e you) to tears The first complaint is Conflict: 2 blocks (1 unsatisfied) !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-libs/openssl:0 (dev-libs/openssl-1.0.1h-r1::gentoo, installed) pulled in by (no parents that aren't satisfied by other packages in this slot) (dev-libs/openssl-1.0.1h-r2::gentoo, ebuild scheduled for merge) pulled in by =dev-libs/openssl-1.0.1h-r2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (net-nds/openldap-2.4.38-r2::gentoo, installed) I assume that the no parents that aren't satisfied ... means that portage could handle this one. Yes, I believe that's how it worked. Portage was being unneccessarily verbose. If you need to you can always emerge -1 openssl to get past the messages There are a few more again with no parents Then comes one that I can't understand virtual/libintl:0 (virtual/libintl-0-r1::gentoo, ebuild scheduled for merge) pulled in by =virtual/libintl-0-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (net-libs/gnutls-3.3.4::gentoo, ebuild scheduled for merge) (virtual/libintl-0::gentoo, installed) pulled in by =virtual/libintl-0 required by (net-analyzer/nmap-6.25::gentoo, installed) (and 31 more with the same problem) This seems to say that nmap-6.25 requires specifically virtual/libintl-0. But I went to net-analyzer/nmap-6.25.ebuild and the only occurrence of libintl is nls? ( virtual/libintl ) in RDEPEND Why does this require specifically virtual/libintl-0 and not permit virtual/libintl-0-r1? It's not nmap doing it, it is gnutls. Look again at the first line (for the -r1 version). Your gnutls is still ~arch and stable hasn't caught up yet. Run this emerge -1 gnutls then continue with your regular world update. In summary, when you get these weird blockers, always check if the higher number version is being pulled in by something ~arch. Then downgrade that offender manually. I would also advise you speed this along by doing this: emerge -av1 @system followed by a full @preserved-rebuild, depclean, revdep-rebuild (don't skimp on these 3, you want to check everything The system set updates slowly and can take forever for stable to catch up. Better to just get your critical base packages onto stable asap. Then the same for perl and python followed by the usual perl-cleaner and python-updater. It should be safe to let the rest of world update at it's own speed Any help would be appreciated. allan -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] update world problem (looks like slot confusion on my part)
On Thu, Jun 19, 2014 at 5:10 PM, Alan McKinnon alan.mckin...@gmail.com wrote: First thing: I understand why you want to go testing - stable, but at least leave portage unstable. A *lot* of ancient stuff has been fixed in ~arch, it's perfectly safe and robust, and most especially all that stupid no parents that aren't satisfied by other packages in this slot has gone away, replaced with something that a) works and b) makes sense and c) does not reduce the poor sysadmin (i.e you) to tears Stable is only three months older than ~arch, though it may very well be much better (can't say I've used the ~arch version). Portage has fortunately been keeping up much better on stable of late. If there are packages that simply aren't acceptable in their stable versions, I'd call that a bug... Rich
Re: [gentoo-user] update world problem (looks like slot confusion on my part)
On 19/06/2014 23:20, Rich Freeman wrote: On Thu, Jun 19, 2014 at 5:10 PM, Alan McKinnon alan.mckin...@gmail.com wrote: First thing: I understand why you want to go testing - stable, but at least leave portage unstable. A *lot* of ancient stuff has been fixed in ~arch, it's perfectly safe and robust, and most especially all that stupid no parents that aren't satisfied by other packages in this slot has gone away, replaced with something that a) works and b) makes sense and c) does not reduce the poor sysadmin (i.e you) to tears Stable is only three months older than ~arch, though it may very well be much better (can't say I've used the ~arch version). Portage has fortunately been keeping up much better on stable of late. Yes, that is true. It's also the one package we Gentoo'ers use more often than anything else, so any non-optimumness shows up very quickly, and gets noticed. If there are packages that simply aren't acceptable in their stable versions, I'd call that a bug... I wouldn't go that far :-) Stable portage gets the job done (after all, the stable code was in unstable for a long time and we all dealt with it OK). As I see it, it's a simple question of effectively communicating the information that portage has to the user. If the dev wants to rate this as a bug then it's already fixed in ~arch and the next step is to stabilize that code -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] [Gentoo-User] emerge --sync likely to kill SSD?
Hello Microcal, I use tmpfs heavily as I have an SSD. Here are some information that can help you : tank woody # mount -v | grep tmpfs devtmpfs on /dev type devtmpfs (rw,relatime,size=8050440k,nr_inodes=2012610,mode=755) tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,size=1610408k,mode=755) shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime) cgroup_root on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755) tmpfs on /var/tmp/portage type tmpfs (rw,size=12G) tmpfs on /usr/portage type tmpfs (rw,size=12G) tmpfs on /usr/src type tmpfs (rw,size=12G) tmpfs on /tmp type tmpfs (rw,size=12G) tmpfs on /home/woody/.mutt/cache type tmpfs (rw) tank woody # cat /etc/fstab # /etc/fstab: static file system information. # # noatime turns off atimes for increased performance (atimes normally aren't # needed); notail increases performance of ReiserFS (at the expense of storage # efficiency). It's safe to drop the noatime options if you want and to # switch between notail / tail freely. # # The root filesystem should have a pass number of either 0 or 1. # All other filesystems should have a pass number of 0 or greater than 1. # # See the manpage fstab(5) for more information. # # fsmountpointtype optsdump/pass # NOTE: If your BOOT partition is ReiserFS, add the notail option to opts. /dev/sda1/ext4 noatime,discard,user_xattr0 1 /dev/sda3/homeext4 noatime,discard,user_xattr0 1 #/dev/sda6/homeext3noatime0 1 #/dev/sda2noneswapsw0 0 tmpfs/var/tmp/portagetmpfssize=12G 0 0 tmpfs/usr/portagetmpfssize=12G 0 0 tmpfs/usr/srctmpfssize=12G0 0 tmpfs/tmptmpfssize=12G0 0 tmpfs/home/woody/.mutt/cache/tmpfs size=12G0 0 #/dev/cdrom/mnt/cdromautonoauto,ro0 0 #/dev/fd0/mnt/floppyautonoauto0 0 tank woody # For the /usr/portage directory, if you reboot, all you have to do is emerge-webrsync or do like me : tank woody # l /usr/ | grep portage 924221 4 drwxr-xr-x 170 root root 4096 1 mars 02:51 portage_tmpfs 6771 0 drwxr-xr-x 171 root root 3500 11 juin 20:40 portage tank woody # The /usr/portage_tmpfs is a backup of the /usr/portage, this avoid me retreiving all portage information from gentoo's servers. Please note that I also use www-misc/profile-sync-daemon in order to store my browsers cache on /tmp. I rarely shutdown my computer :) Have fun On 19/06/2014 04:36, microcai wrote: rsync is doing bunch of 4k ramdon IO when updateing portage tree, that will kill SSDs with much higher Write Amplification Factror. I have a 2year old SSDs that have reported Write Amplification Factor of 26. I think the only reason is that I put portage tree on this SSD to speed it up. what is the suggest way to reduce Write Amplification of a portage sync ?
Re: [gentoo-user] Dependency conflict. openjpeg ffmpeg
Dale wrote:
OK. First, corrected the version and then tried with no version at all
as shown below. Going to start here since well, this is where this
suggestion started. I created the files in env and deeper but either it
isn't seeing it for some reason OR it isn't a option to change. I'm
leaning toward the first since most likely I didn't do something right.
;-) It wouldn't be the first time but it is the first time I put
anything in the env directory, which I had to create by the way.
Current paths to file:
/etc/portage/env/media-libs
/etc/portage/env/media-video
File names:
openjpeg
ffmpeg
Contents of both files:
ABI_X86=32 64
So, what am I missing there? Output of emerge:
root@fireball / # emerge -va =media-libs/openjpeg-1.4-r1
=media-libs/openjpeg-2.0.0 media-video/ffmpeg
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R] media-libs/openjpeg-1.4-r1 USE=-doc {-test} 0 kB
[ebuild R] media-libs/openjpeg-2.0.0:2 USE=-doc -static-libs
{-test} 0 kB
[ebuild R ~] media-video/ffmpeg-2.2.3-r1:0/52.55.55 USE=3dnow
3dnowext X aac alsa bzip2 encode faac fontconfig frei0r hardcoded-tables
iconv jpeg2k mmx mmxext mp3 network opengl sdl sse sse2 theora threads
truetype vorbis x264 xvid zlib -aacplus (-altivec) -amr -amrenc
(-armv5te) (-armv6) (-armv6t2) (-armvfp) -avx -avx2 -bindist -bluray
-cdio -celt -cpudetection -debug -doc -examples -fdk -flite -fma3 -fma4
-gme -gnutls -gsm -iec61883 -ieee1394 -jack -ladspa -libass -libcaca
-libsoxr -libv4l (-mips32r2) (-mipsdspr1) (-mipsdspr2) (-mipsfpu)
-modplug (-neon) -openal -openssl -opus -oss -pic -pulseaudio -quvi
-rtmp -schroedinger -speex -sse3 -sse4 -sse4_2 -ssh -ssse3 -static-libs
{-test} -twolame -v4l -vaapi -vdpau -vpx -wavpack -webp -x265 -zvbi
ABI_X86=(64) -32 (-x32) FFTOOLS=aviocat cws2fws ffescape ffeval
ffhash fourcc2pixfmt graph2dot ismindex pktdumper qt-faststart trasher 0 kB
Total: 3 packages (3 reinstalls), Size of downloads: 0 kB
Would you like to merge these packages? [Yes/No] n
Quitting.
root@fireball / #
Note the ABI part isn't changing. Could it be because of some USE flag
combo I have set? I do something . . . wrong?? Just for giggles, going
to post the original error again.
WARNING: One or more updates/rebuilds have been skipped due to a
dependency conflict:
media-libs/openjpeg:0
(media-libs/openjpeg-1.5.1:0/0::gentoo, ebuild scheduled for merge)
conflicts with
=media-libs/openjpeg-1.3-r2:0[abi_x86_64(-)] required by
(media-video/ffmpeg-2.2.3-r1:0/52.55.55::gentoo, installed)
Nothing to merge; quitting.
Dale scratches his head
Thanks.
Dale
:-) :-)
OK. This seemed to have fixed the problem.
USE=-jpeg2k
If everything still works then I guess I no longer need that USE flag.
;-) Now to go undo the other stuff I tried.
Dale
:-) :-)
--
I am only responsible for what I said ... Not for what you understood or how
you interpreted my words!
Re: [gentoo-user] update world problem (looks like slot confusion on my part)
On Thu, Jun 19 2014, Alan McKinnon wrote: On 19/06/2014 21:17, gottl...@nyu.edu wrote: There are a few more again with no parents Then comes one that I can't understand virtual/libintl:0 (virtual/libintl-0-r1::gentoo, ebuild scheduled for merge) pulled in by =virtual/libintl-0-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (net-libs/gnutls-3.3.4::gentoo, ebuild scheduled for merge) (virtual/libintl-0::gentoo, installed) pulled in by =virtual/libintl-0 required by (net-analyzer/nmap-6.25::gentoo, installed) (and 31 more with the same problem) This seems to say that nmap-6.25 requires specifically virtual/libintl-0. But I went to net-analyzer/nmap-6.25.ebuild and the only occurrence of libintl is nls? ( virtual/libintl ) in RDEPEND Why does this require specifically virtual/libintl-0 and not permit virtual/libintl-0-r1? It's not nmap doing it, it is gnutls. Look again at the first line (for the -r1 version). Your gnutls is still ~arch and stable hasn't caught up yet. Run this emerge -1 gnutls then continue with your regular world update. In summary, when you get these weird blockers, always check if the higher number version is being pulled in by something ~arch. Then downgrade that offender manually. I am trying to understand this but having difficulty. Perhaps the whole problem is caused by later complaints from portage asking me to keyword items. I understand that gnutls-3.3.4 needs the -r1 version of virtual/libintl-0. I don't understand why the other packages (nmap-6.25 and 31 others) are not happy with the -r1. Maybe this is just bad wording on portage's part and the real problem is that the -r1 version is keyworded and I am going stable without virtual/libintl in package.accept-keywords. I don't think that emerge -1 gnutls will help since it simply re-installs the stable 2.12.23-r6. The question is why do I need the testing gnutls-3.3.4 ? The answer according to portage (further down in the error messages) is The following keyword changes are necessary to proceed: (see package.accept_keywords in the portage(5) man page for more details) # required by net-im/empathy-3.10.3 # required by gnome-base/gnome-core-apps-3.10.0 # required by gnome-base/gnome-3.10.0 # required by @selected # required by @world (argument) =net-libs/gnutls-3.3.4 ~amd64 However I currently have empathy-3.10.3 and the ebuild for stable net-im/empathy-3.10.3 has in COMMON_DEPEND =net-libs/gnutls-2.8.5:= My current gnutls is 2.12.23-r6. Is the problem the := ? Anyway I don't believe STABLE empathy should require TESTING gnutls. thanks again for helping and thanks in advance for clearing up my confusion. allan
