/opt/FJSVmpd/bin/iompadm info

IOMP: vhba0
Element:
DISK: ETERNUS_DXL- 010309-0000-0002 (sdf)
PATH:
sdf 0000:02:00.0 standby "online" 11, 11, 2
sdf 0000:02:00.0 active "online" 10, 10, 0
sdf 0000:03:00.0 fail "no such device or address" 11, 11, 2
sdf 0000:03:00.0 fail "no such device or address" 10, 10, 0

DISK: ETERNUS_DXL- 010309-0000-0000 (sdg)
PATH:
sdg 0000:02:00.0 standby "online" 11, 11, 2
sdg 0000:02:00.0 active "online" 10, 10, 0
sdg 0000:03:00.0 fail "no such device or address" 11, 11, 2
sdg 0000:03:00.0 fail "no such device or address" 10, 10, 0

Nie zwracajcie uwagi na fail na jednej karcie – chwilowo światłowody od strony macierzy wpięte są do jednego przełącznika. Ważne to, że mamy dwa wolumeny i dwa urządzenia /dev/sdf i /dev/sdg.
Na AMS2100 wygląda to inaczej:

/opt/DynamicLinkManager/bin/dlnkmgr view -drv
PathID HDevName Device LDEV
000000 sddlmae /dev/sdb AMS.83004182.0001
000001 sddlmaf /dev/sdc AMS.83004182.0002
000002 sddlmag /dev/sdd AMS.83004182.0003
000003 sddlmah /dev/sde AMS.83004182.0004
000008 sddlmae /dev/sdh AMS.83004182.0001
000009 sddlmaf /dev/sdi AMS.83004182.0002
000010 sddlmag /dev/sdj AMS.83004182.0003
000011 sddlmah /dev/sdk AMS.83004182.0004
KAPL01001-I The HDLM command completed normally. Operation name = view, completion time = 2012/01/27 22:09:41

Mamy /dev/sddlmae, które to jest złączeniem /dev/sdb i /dev/sdh (analogicznie reszta). Możemy odwołać się do tego pierwszego urządzenia i wtedy mamy wielościeżkowość zapewnioną, ale równie dobrze możemy korzystać z pojedynczych urządzeń (naturalnie bez MPIO).
Niestety domyślnie składowe urządzenia są widoczne. Jeśli podłączając zasób odwołujemy się bezpośrednio do nazwy /dev/sddlmae to nie ma problemu. Gorzej, gdy montujemy korzystając z label‘i. Jako, że może istnieć wiele urządzeń tak samo nazwanych, system wybierze pierwsze i z niego skorzysta. W takim przypadku jak mój pierwsze oznacza to przez jedną ścieżkę (fdisk -l 2>&1|grep ^Disk).

Swego czasu przy przenoszeniu danych z macierzy Fujitsu na Hitachi nie zwróciłem na to uwagi, a to spowodowało krótką niedostępność…

Gdyby się ktoś nad tym zastanawiał, to UUID niczego nie zmienia:

/dev/sdb1: LABEL="database" UUID="e275b221-be9f-449b-a0ff-88de3a01799a" TYPE="ext3"
/dev/sdh1: LABEL="database" UUID="e275b221-be9f-449b-a0ff-88de3a01799a" TYPE="ext3"
/dev/sddlmae1: LABEL="database" UUID="e275b221-be9f-449b-a0ff-88de3a01799a" TYPE="ext3"

Kto dopisze jak ukryć urządzenia składowe przez udev?

CPU Monitor łączy się z maszyną przez SSH i wykonuje proste komendy, żeby pobrać dane do wykresów. Pobieżnie przejrzałem źródła i widzę, że w przypadku Linuksa (LinuxMonitoredServer.java) informacje o serwerze wyciągane są za pomocą:

echo -n 'Number Of Processors: '; cat /proc/cpuinfo | grep processor | wc -l; cat /proc/cpuinfo | egrep -m 2 'cpu MHz|model name';cat /proc/meminfo | grep MemTotal:

natomiast same dane pochodzą z:

vmstat <refreshRate>

Dla MacOS (MacOSMonitoredServer.java) jest to:

system_profiler -detailLevel mini | egrep 'Number.Of.Processors:|Memory: |Processor.Name|Processor.Speed

oraz

iostat -w <refreshRate> -n 1

a dla Solaris (SolarisMonitoredServer.java):

echo -n 'Number Of Processors: '; /usr/sbin/psrinfo | wc -l;/usr/sbin/psrinfo -v | egrep 'MHz' | head -1; /usr/sbin/prtconf | grep Memory

i

iostat <refreshRate>

W przyszłości ma również być dodana obsługa AIX i HP-UX. Zapowiadana była również możliwość monitorowania sieci.

Konfiguracja zawiera się w pliku XML i wygląda mniej więcej tak (za dokumentacją):

<?xml version = ’1.0′ encoding = ‘UTF-8′?>
<CPUMonitor Title=”Compute Nodes” xmlns=”http://www.dominicgiles.com/cpumonitor”>
<MonitoredNode>
<HostName>localhost</HostName>
<Username>root</Username>
<Password>mypassword</Password>
<Comment>My Computer</Comment>
</MonitoredNode>
</CPUMonitor>

Jedyny parametr, którym możemy sterować z poziomu programu to czas odświeżania. Proste i w miarę przejrzyste. Spróbujcie sami.

A OpenBSD 5.0 beta nadal nie mam :/

localhost ~ # df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                 63G   63G     0 100% /
/dev/VG1/root          63G   63G     0 100% /

Auć! Brak miejsca. Na szczęście jest LVM, damy radę!

localhost ~ # lvresize -L +32G VG1/root
Extending logical volume root to 96.00 GiB
/etc/lvm/backup/VG1.tmp: write error failed: No space left on device
Backup of volume group VG1 metadata failed.
Logical volume root successfully resized
/etc/lvm/cache/.cache.tmp: write error failed: No space left on device

To, że nie ma miejsca, to wiem. Właśnie próbuję rozwiązać ten problem.
A co z wolumenem?

localhost ~ # lvdisplay
--- Logical volume ---
LV Name                /dev/VG1/root
VG Name                VG1
LV UUID                lXGuyU-X31a-FFLK-wrAg-Uhm6-civD-HEqQzo
LV Write Access        read/write
LV Status              available
# open                 1
LV Size                96.00 GiB
Current LE             24576
Segments               1
Allocation             inherit
Read ahead sectors     auto
- currently set to     256
Block device           254:0

/etc/lvm/cache/.cache.tmp: write error failed: No space left on device

Znów problem braku miejsca przy wyświetlaniu informacji? Tylko spokój może nas uratować!

Pod koniec zeszłego roku, na ostatnim z MLUGów mówiłem o LVM. Z racji ograniczeń czasowych i podstawowego poziomu przedstawienia tematu nie można było o wszystkim powiedzieć. A zauważyłem na forach, że problem z miejscem, który powyżej przytoczyłem zdarza się od czasu do czasu.
Otóż, komunikat dotyczy systemu plików, nie LVM. Ale to LVM go zgłasza, bo próbuje zapisać swoje informacje w /etc/lvm/cache/.cache (jest to plik tekstowy, można go przestudiować, ale nie polecam ręcznej edycji!). W gruncie rzeczy może go nie być czy jak w tym przypadku może się nie zapisać. Straty nie będzie. Wprawdzie niektóre narzędzia z niego korzystają dla przyspieszenia, ale da się go odtworzyć na podstawie istniejących wolumenów.
Po zwiększeniu systemu plików (w moim przypadku resize2fs), przy kolejnym wywołaniu vgscan (ręcznie lub przy restarcie systemu), plik zostanie zapisany z aktualnymi informacjami.
Zmiany w pliku są robione ‘z głową’ – czyli pierw kopiowany jest do /etc/lvm/cache/.cache.tmp, a dopiero potem zmieniany. I właśnie w przypadku braku miejsca w systemie plików ta kopia nie zostanie zapisana.

Moje środowisko:

• System operacyjny: GNU/Linux
• Dystrybucja: Gentoo Base System release 2.0.2
• Serwer WWW: Lighttpd
• Bacula: 5.0.3 (bacula-gui)
• Perl: 5.12.3

1. Przygotowanie środowiska

Zakładam, że coś tam w systemie już jest, więc o np. Perl nie piszę. Z dodatków będzie:

dev-perl/GD dev-perl/GDGraph dev-perl/HTML-Template perl-core/CGI dev-perl/Expect dev-perl/Time-modules dev-perl/Date-Calc

Do tego flagi:

dev-perl/GD gif jpeg png truetype
media-libs/gd truetype

2. Instalacja Bweb

Jeśli mamy już działające środowisko Bacula (director, storage i client), wystarczy pobrać paczkę bacula-gui (na chwilę obecną 5.0.3) i z niej wykonać instalację Bweb.
Po rozpakowaniu (tar xzvf bacula-gui-5.0.3.tar.gz -C <path>) zalecam przejrzenie pliku <path>/bweb/INSTALL. W skrócie instalacja wygląda jak poniżej (przy czym na początku tylko testy środowiska, więc nie jest to wymagane).

cd <path>bweb/lib
../cgi/bweb.pl
../cgi/bgraph.pl

Dalej modyfikujemy bazę :

cd <path>bweb
mysql bacula < script/bweb-mysql.sql

3. Uruchomienie

Na koniec uruchamiamy lighttpd (musi być wcześniej zainstalowany) za pomocą skryptu ./script/starthttp i łączymy się z maszyną dowolną przeglądarką na porcie 9180 lub modyfikujemy konfigurację lighttpd dodając stosowne dyrektywy z pliku script/httpd.conf
Niezależnie od tego, którą drogę wybierzemy, pozostaje jeszcze skonfigurowanie połączeń z bazą. Albo poprzez edycję pliku bweb.conf, albo na stronie Bweb.

Statystyki do raportu tygodniowego

Poniżej dwa odnośniki z krótkimi informacjami jak znaleźć nowe urządzenia SCSI i ich WWN. Można od tego zacząć inwentaryzację.

• Scanning SCSI Bus and HBA Devices in Linux
• Linux Find FC ID (WWN) of a disk/LUN

Dla kart QLogic i Emulex WWPN można znaleźć w informacjach z /proc/scsi/<moduł>/<id>, np. dla Qlogic QLA2312 może być to /proc/scsi/qla2xxx/2 i sekcja SCSI Device Information.
A jeśli używamy sysfs, to szukać musimy w np. /sys/class/scsi_host/host5/device/fc_host\:host5/port_name

Pierwsza to Intel 3945ABG:

02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
Subsystem: Intel Corporation Device 1021
Flags: bus master, fast devsel, latency 0, IRQ 46
Memory at dfc00000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 00-18-de-ff-ff-94-de-77
Kernel driver in use: iwl3945
Kernel modules: iwl3945

Druga – Realtek RTL8187SE (chyba MSI)

02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8187SE Wireless LAN Controller (rev 22)
Subsystem: Micro-Star International Co., Ltd. Device 6894
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at d000 [size=256]
Memory at dfc00000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 00-00-8e-93-c9-92-1d-00
Kernel driver in use: r8180
Kernel modules: r8187se

Najświeższe jądro (gentoo-sources). Tą drugą obsługuje mocno eksperymentalny moduł (w staging drivers od 2.6.29).

Firmware dla karty Intel’a do ściągnięcia z:

• Intel Wireless

Do Realtek’a nie pamiętam czy coś pobierałem, a maszyna z tą kartą gdzieś mi się zawieruszyła pod biurkiem :> Niemniej polecam odwiedzić:

• Linux Wireless: rtl8187
• Realtek Linux wireless driver

W kolejce na biurku czekają jeszcze (opisy sprzedawców z Allegro):

• Broadcom WIFI DO HP COMPAQ MiniPCI-E WLAN 54Mbit
• INTEL 5300 Wireless LAN Half Mini PCI-E 533AN_HMW
• Half Mini Pci-e WLAN Card For Intel 512AN WiFi 300

Zacznę od dhcpcd, o którym pisałem wcześniej w kontekście ipv4ll (aka. zeroconf). Aktualna wersja dostępna dla Gentoo – 5.2.10 nie wspiera opcji timeout dla interfejsu, jedynie globalnie (definiowane w dhcpcd.conf). Po dyskusji z Royem Marples zostało to poprawione, jednakże zanim trafi do stabilnej wersji, a ta do drzewa portage, trochę czasu minie.

Poprawki mamy, możemy więc skompilować oprogramowanie ze źródeł, zainstalować na miejsce aktualnego i używać do czasu aktualizacji. Można też – bardziej elegancko, przygotować własny ebuild i zaktualizować program korzystając z emerge. W przypadku wspomnianego net-misc/dhcpcd poprawka może wyglądać tak (zmiana src_unpack) w pliku ebuild, który dla czytelności możemy oznaczyć kolejnym numerkiem, np. dhcpcd-5.2.11-r1.ebuild):

src_unpack() {
unpack ${A}
cd "${S}"

if ! use zeroconf; then
elog "Disabling zeroconf support"
{
echo
echo "# dhcpcd ebuild requested no zeroconf"
echo "noipv4ll"
} >> dhcpcd.conf
fi

# patches go here...
epatch "${FILESDIR}"/dhcpcd-5.2.11-tmout.diff
}


A plik dhcpcd-5.2.11-tmout.diff może mieć taką postać:

--- /tmp/dhcpcd-5.2.11/dhcpcd.c 2011-02-04 15:56:03.000000000 +0100
+++ /tmp/dhcpcd.c 2011-03-30 09:02:44.000000000 +0200
@@ -2011,17 +2011,20 @@ main(int argc, char **argv)
}
}
}
+ if (options & DHCPCD_MASTER)
+ i = if_options->timeout;
+ else
+ i = ifaces->state->options->timeout;
if (opt == 0 &&
options & DHCPCD_LINK &&
!(options & DHCPCD_WAITIP))
{
syslog(LOG_WARNING, "no interfaces have a carrier");
daemonise();
- } else if (if_options->timeout > 0) {
+ } else if (i > 0) {
if (options & DHCPCD_IPV4LL)
options |= DHCPCD_TIMEOUT_IPV4LL;
- add_timeout_sec(if_options->timeout,
- handle_exit_timeout, NULL);
+ add_timeout_sec(i, handle_exit_timeout, NULL);
}
}
free_options(if_options);


Pliki można ściągnąć z mojego zgłoszenia w Gentoo’s Bugzilla.

Jeśli zostawimy to wszystko w oryginalnych katalogach (w /usr/portage) podczas kolejnej synchronizacji zostanie usunięte. Jeżeli więc poprawki nie mają charakteru okazjonalnego, możemy zabezpieczyć się kopiując wybraną gałąź drzewa w osobne miejsce i konfigurując zmienna PORTDIR_OVERLAY w /etc/make.conf (musi wskazywać na nasze drzewo). Pamiętać należy, że struktura naszego własnego drzewa musi być podobna do oryginalnego.

localhost ~ # mkdir -p /usr/local/portage/net-misc
localhost ~ # cp -rp /usr/portage/net-misc/dhcpcd /usr/local/portage/net-misc/
localhost ~ # echo "PORTDIR_OVERLAY=\"/root/portage\"" >> /etc/make.conf

Po takim zabiegu widać będzie już nasze własne drzewo przy kompilacji pakietu:

localhost ~ # emerge -pv net-misc/dhcpcd

These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] net-misc/dhcpcd-5.2.10-r3 USE="zeroconf" 0 kB [1]

Total: 1 package (1 new), Size of downloads: 0 kB
Portage tree and overlays:
[0] /usr/portage
[1] /usr/local/portage

W przypadku aktualizacji wygląda to tak:

localhost dhcpcd # emerge -pv net-misc/dhcpcd

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild U ] net-misc/dhcpcd-5.2.10-r3 [5.2.10-r2] USE="zeroconf" 0 kB [0=>1]

Total: 1 package (1 upgrade), Size of downloads: 0 kB
Portage tree and overlays:
[0] /usr/portage
[1] /root/portage

Przeczytaj więcej:

• HOWTO: Installing 3rd Party Ebuilds [http://www.gentoo-wiki.info/HOWTO_Installing_3rd_Party_Ebuilds]
• Ebuild HOWTO [http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1]
• HOWTO: Local Rsync Mirror http://www.gentoo-wiki.info/HOWTO_Local_Rsync_Mirror

Q: A co jeśli nie robimy tego na bieżąco?
A: No może być różnica w EAPI (Ebuild Application Programming Interface), ale zazwyczaj aktualizacja sys-apps/portage wcześniej rozwiąże sprawę.

Q: A co jeśli nie aktualizowaliśmy dość długo?
A: Jak wyżej. W przypadku problemów można spróbować przebudować sys-apps/portage bez zależności (emerge --nodep portage), to samo zrobić z dev-lang/python, a następnie przebudować ‘normalnie’ oba te pakiety.

Q: A co jeśli bardzo, bardzo mocno zapuściliśmy nasz system?
A: Huh. Czeka nas droga przez mękę. Zadajmy sobie pytanie czy w ogóle chcemy to robić. Jeśli to system wewnętrzny, może warto kierować się zasadą g… (jak działa i nie śmierdzi, to nie ruszaj)? Gorzej jak chcemy coś doinstalować, źródeł starych wersji nie ma, drzewo aktualne wymaga EAPI >= 3. Wtedy wyglądać to może tak:

dolly ~ # cat /etc/gentoo-release
Gentoo Base System release 1.12.9
dolly ~ # uname -a
Linux dolly 2.6.20-gentoo #1 PREEMPT Thu Feb 8 10:12:04 CET 2007 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux
dolly ~ # emerge --info
Portage 2.1.2-r9 (default/linux/x86/10.0, gcc-4.1.2, glibc-2.5-r0, 2.6.20-gentoo i686)
=================================================================
System uname: 2.6.20-gentoo i686 Pentium III (Coppermine)
Gentoo Base System release 1.12.9
dolly ~ # python -V
Python 2.4.3

No cóż. Ja ciągle wierzę, że da się z tego wybrnąć (choć walczę już dość długo). Po pierwsze profil, który był kiedyś już dawno jest zapomniany.

dolly ~ # eselect profile list
Available profile symlink targets:
[1] default/linux/x86/10.0 *
dolly ~ # emerge portage
Calculating dependencies \
!!! All ebuilds that could satisfy "portage" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-apps/portage-2.1.6.7 (masked by: profile)
- sys-apps/portage-9999 (masked by: required EAPI 2, supported EAPI 0)
- sys-apps/portage-2.1.8.3 (masked by: required EAPI 2, supported EAPI 0)
- sys-apps/portage-2.2.0_alpha26 (masked by: required EAPI 2, supported EAPI 0)
- sys-apps/portage-2.1.9.25 (masked by: required EAPI 2, supported EAPI 0)
- sys-apps/portage-2.1.6.13 (masked by: required EAPI 1, supported EAPI 0)
- sys-apps/portage-2.1.9.42 (masked by: required EAPI 2, supported EAPI 0)
For more information, see MASKED PACKAGES section in the emerge man page or
refer to the Gentoo Handbook.


Spróbujmy zatem innego (to da się zrobić tylko ręcznie):

dolly ~ # rm /etc/make.profile
dolly ~ # ln -s /usr/portage/profiles/default/linux/x86/2008.0 /etc/make.profile
dolly ~ # emerge -pv portage
!!! Your current profile is deprecated and not supported anymore.
!!! Please upgrade to the following profile if possible:
default/linux/x86/10.0
To upgrade do the following steps:
# Check 'eselect profile list'.
# Find the number that corresponds with the default/linux/x86/10.0 profile.
# Use 'eselect profile set ' to set a new /etc/make.profile symlink.
#
# Reference: http://www.gentoo.org/doc/en/gentoo-upgrading.xml
# See: "General instructions" in Section 3. "Profile updating instructions"
These are the packages that would be merged, in order:
Calculating dependencies |
!!! All ebuilds that could satisfy ">=app-admin/eselect-python-20091230" have been masked.
!!! One of the following masked packages is required to complete your request:
- app-admin/eselect-python-20100321 (masked by: required EAPI 1, supported EAPI 0)
- app-admin/eselect-python-20091230 (masked by: required EAPI 1, supported EAPI 0)
- app-admin/eselect-python-99999999 (masked by: required EAPI 2, supported EAPI 0)
For more information, see MASKED PACKAGES section in the emerge man page or
refer to the Gentoo Handbook.
(dependency required by "sys-apps/portage-2.1.6.7" [ebuild])


Jesteśmy już bliżej, ale nadal się nie udaje. To może python bez zależności?

dolly ~ # emerge --nodep python
* IMPORTANT: 5 news items need reading for repository 'gentoo'.
* Use eselect news to read news items.
>>> Emerging (1 of 1) dev-lang/python-2.6.6-r2
* Python-2.6.6.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ]
* python-gentoo-patches-2.6.6-r2.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ]
/usr/portage/eclass/python.eclass: line 63: syntax error in conditional expression: unexpected token `('
/usr/portage/eclass/python.eclass: line 63: syntax error near `^(('
/usr/portage/eclass/python.eclass: line 63: ` if [[ "${version_components_groups}" =~ ^((\!)?[[:alnum:]_-]+\?\ )?${version_components_group_regex}(\ ${version_components_group_regex})?$ ]]; then'
*
* ERROR: dev-lang/python-2.6.6-r2 failed.
* Call stack:
* ebuild.sh, line 1867: Called source '/usr/portage/dev-lang/python/python-2.6.6-r2.ebuild'
* python-2.6.6-r2.ebuild, line 8: Called inherit 'autotools' 'eutils' 'flag-o-matic' 'multilib' 'python' 'toolchain-funcs'
* ebuild.sh, line 1224: Called die
* The specific snippet of code:
* qa_source "$location" || die "died sourcing $location in inherit()"
* The die message:
* died sourcing /usr/portage/eclass/python.eclass in inherit()
*
* If you need support, post the topmost build error, and the call stack if relevant.
* A complete build log is located at '/var/tmp/portage/dev-lang/python-2.6.6-r2/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/dev-lang/python-2.6.6-r2/temp/die.env'.
*
>>> Failed to emerge dev-lang/python-2.6.6-r2, Log file:
>>> '/var/tmp/portage/dev-lang/python-2.6.6-r2/temp/build.log'


E-e! To też nie zadziała. A jakby tak przenieść portage ze świeższego systemu – to nie jest trudne.

tar cvf /tmp/portage.tar `qlist sys-apps/portage`

Takie archiwum rozpakowujemy na docelowej maszynie i walczymy dalej.

Niestety w moim przypadku nie powiodło się. To może dorzucimy python’a? Przenosimy w sposób jak powyżej, dla bezpieczeństwa rozpakować możemy gdzieś na boku, w $PATH wstawiamy ścieżkę do katalogu z binariami, dodatkowo ustawiamy zmienną $LD_LIBRARY_PATH na katalog lib/ i mamy świeższe oprogramowanie do dyspozycji.
No już prawie witam się z gąską… Dalej klapa. Ale broni nie złożę tak łatwo!

Drogi czytelniku! Jeśli miałeś podobne problemy i je rozwiązałeś, a jednocześnie chcesz mi popsuć krótki weekend, wpisz proszę swoje uwagi w komentarzu poniżej.

localhost ~ # qsize -b openssh nano
net-misc/openssh-5.8_p1: 21 files, 15 non-files, 2077068 bytes
app-editors/nano-2.2.5: 83 files, 79 non-files, 347806 bytes

To samo możemy uzyskać następującym łamańcem:

ls -l `qlist openssh` 2>/dev/null|awk '{SUM += $5} END {print SUM}'

Co to robi? Korzystając z qlist (również z portage-utils) wyświetlam listę plików przynależnych do danego pakietu, a następnie ich rozmiar (piąta kolumna zwracana przez ls -l) sumuję za pomocą awk.
To 2>/dev/null jest niezbędne jak ktoś ręcznie usuwa pliki. qlist o tym nie wie. qsize zwraca dokładnie ten sam wynik, ale robi to szybciej.

Oprócz qlist i qsize w portage-utils jest jeszcze wiele innych ciekawych i szybkich narzędzi. Np. qfile sprawdzi nam czy dany plik należy do jakiegoś pakietu (czyli odwrotnie do qlist), qsearch szybko poszuka nam pakietu, a quse pokaże który pakiet skompilowany jest z podaną flagą USE.

Po opis pozostałych programów odsyłam do dokumentacji.

q --help
qatom <pkg>           : split atom strings
qcache <action> <args> : search the metadata cache
qcheck <pkgname>       : verify integrity of installed packages
qdepends <pkgname>       : show dependency info
qfile <filename>      : list all pkgs owning files
qglsa <action> <list> : check GLSAs against system
qgrep <misc args>     : grep in ebuilds
qlist <pkgname>       : list files owned by pkgname
qlop <pkgname>       : emerge log analyzer
qmerge <pkgnames>      : fetch and merge binary package
qpkg <misc args>     : manipulate Gentoo binpkgs
qsearch <regex>         : search pkgname/desc
qsize <pkgname>       : calculate size usage
qtbz2 <misc args>     : manipulate tbz2 packages
quse <useflag>       : find pkgs using useflags
qxpak <misc args>     : manipulate xpak archives