Re: ext3 et rpmdb

Page principale

Répondre à ce message
Auteur: Olivier Allard-Jacquin
Date:  
À: guilde
Sujet: Re: ext3 et rpmdb
    Bonsoir,

Yves Martin a écrit :
> Selon Olivier Allard-Jacquin <olivieraj@???>:
>
>> il semblerait que ton bs=1024 viennent du faite que tes partitions sont
>> assez petites, non ? Donc cette manipulation ne devrait pas trop prendre
>> de temps.
>
> Effectivement c'est petit, c'est mon / de 10 Go qui contient tout mon système et
> installé à l'époque avec la Mandriva 2007.0.
>
> J'ai créé une partition LVM que j'ai monté sur /var/lib/rpm (pour comparer avec
> un loopback bs=1024) et voici ce que j'obtiens après moulinage:
>
> root /var/lib> strace -f -o /home/yma/strace-rpm-rebuilddb.log rpm --rebuilddb
> error: failed to replace old database with new database!
> error: replace files in /var/lib/rpm with files from /var/lib/rpmrebuilddb.1626
> to recovererror: failed to remove directory /var/lib/rpmrebuilddb.1626:
> Directory not empty
>
> Étrange - cette opération fonctionne bien si /var/lib/rpm est sur un loopback fs
> mais pas si c'est un /dev/mapper/vg01-rpm ? mais c'est codé comment rpm ??


    A priori, rpm ne devrait pas à avoir à regarder ce qu'il y a en-dessous
du filesystem. La taille des blocks ne devrait pas lu pose de problème.


    Le "rpm --repuilddb" fait quoi exactement ? Un audit de tout le contenu
du disque dur, fichier par fichier ? Dans ce cas là, est-ce qu'il ne
rajouterai pas à sa base de données des fichiers que tu es en train de
créer justement avec rpmbuild ?


    C'est un peu comme lancer un sniffage réseau sur une machine dont on
est connectée via telnet/ssh : la machine à distance va afficher des
paquets qui sont échangés par elle, mais comme cela génère du trafic
réseau à destination du client telnet/ssh, le sniffer de paquets va
envoyer encore plus de données, etc... Bref, tu génères des données qui
elles-mêmes en générer.


> Comme je ne comprends pas, j'ai fait un strace dans un pipe avec "cat
> strace-rpm-rebuilddb.log | gzip -c > strace-rpm-rebuilddb.log.gz" (pas assez de
> disque pour tout conserver)
>
> Question subsidiaire:
> - comment lire la fin du fichier gz (300 Mo) sans faire exploser ma RAM et mon
> swap (ce que zless "G" fait...) en sachant que le contenu non compressé doit
> bien prendre un dizaine de Go que je n'ai pas sous la main.


    avec "dd" je dirais :
gzip -cd strace-rpm-rebuilddb.log.gz | dd if=- bs=1000
skip=NOMBRE_KILO_OCTET_A_NE_PAS_AFFICHER


> En gros, est-ce qu'il existe un outil qui permettrait de jeter le contenu
> intermédiaire du stream gunzip pour ne conserver que les 200 derniers Mo par
> exemple ?


    "dd" ne pourra pas s'arrêter de lui-même à 200Mo de la fin. Par contre,
tu peux savoir la taille du flux décompressé :


gzip -cd strace-rpm-rebuilddb.log.gz | wc -c

Disons que cela te donne 1.000.000.000 octets

Dans ce cas là, pour avoir les 200 derniers Mo, tu fais :

gzip -cd strace-rpm-rebuilddb.log.gz | dd if=- bs=1000 skip=$(( 1000000
- 200000 ))

Note: Pour faire simple, j'ai considéré que 1ko = 1000 octets

    Cordialement,


                        Olivier
-- 
~~~~~~~  _____/\_____  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix /   _ \/ _   \    Olivier Allard-Jacquin
       /   / \  / \   \   Web:  http://olivieraj.free.fr/
      /___/  /  \  \___\  Mail: olivieraj@???
~~~~ /////  ///\\\  \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!