(ɔ) CC-SA ↄ⃝

Latest

Transférer des fichiers entre deux ordinateurs Linux

Le mail ? Impossible quand la taille est trop importante (des Go).

La commande scp ? Implique d’activer ssh, de créer sa paire de clés, d’ouvrir le firewall

La commande rsync ? Elle est bien cette commande, mais là aussi faut sortir l’artillerie !

Le partage NFS ? Bon là, ça se complique 😦

La commande netcat ? Oui 🙂

La machine destination écoute le port 4444
et détarre ce qu’elle reçoit
nc -l 4444 | tar x
La machine source tarre les fichiers
et les envoient sur le port 4444
de la machine destination (192.168.44.44)
tar c fichiers | nc 192.168.44.44 4444

On peut aussi réduire la bande passante en ajoutant à la commande tar l’option -z (gzip), ou l’option -j (bzip2) qui compresse mieux mais nécessite plus de ressources CPU.

    Sur les distributions récentes, je conseille les options :

  • --lzop –> Compression presque aussi bonne que gzip, mais nécessite moins de ressources CPU et mémoire 🙂
  • --xz –> Compression de folie (un peu plus que bzip2) mais consomme un max de ressources CPU et mémoire !

Donc choisir le bon niveau de compression selon le goulet d’étranglement : ressources CPU/Mémoire ou bande passante réseau.

Attention, plusieurs implémentations de netcat existent. J’utilise la version fournie par Ubuntu 12.04 qui est celle d’OpenBSD. La ligne de commande est quelquefois différente, exemple : -l -p 4444 au lieu de -l 4444

Diablox9 et ses 600 000 abonnés

La chaîne principale de Diablox9 a atteint 600 000 abonnés le 16 juillet 2012 !
–> la preuve en vidéo

Après 550 000 abonnés en juin, et bientôt 650 000 abonnés mi-août,
on peut estimer que 50 000 nouveaux internautes s’abonnent
chaque mois à sa chaîne principale : c’est tout simplement incroyable !

Optimiser son ordinateur avec un SSD

Le disque dur est bien souvent le goulet d’étranglement qui ralentit la machine. Petit à petit, il est remplacé par une nouvelle technologie : le SSD. C’est de la mémoire flash avec la même connectique que les disques durs. Donc, plus de pièces mécaniques en mouvement (pas de disque).

Comme toute nouvelle technologie, c’est plus cher. Dix fois plus cher !

SSD 80€ pour 128 Go
Disque dur 80€ pour 1.5 To

Mais les prix baissent. Maintenant, le SSD devient abordable.

De plus, le SSD est le choix le plus astucieux avec un ordinateur portable par rapport au disque dur :

  • 128 Go suffisent (merci d’archiver photos, vidéos et données personelles sur un NAS)
  • plus rapide
  • plus économe en énergie
  • plus silencieux
  • plus robuste (le disque dur et sa tête de lecture craignent les chocs)
  • tout aussi fiable (les SSD récents ne perdent pas plus de données qu’un disque dur magnétique)

J’ai donc acheté un ordinateur portable sans disque dur chez pcubuntoo.fr, et un SSD chez axtorage.com (le Samsung 830 128Go).

Voici mes conseils pour en obtenir les meilleures performances :

  • Choisir n’importe quel SSD récent supportant la technologie TRIM
    car ils sont tous bien plus véloces que les disques durs et, comparés aux disques durs, leurs performances se valent.

     
  • Les partitions crées avec l’installateur Ubuntu 12.04 sont bien alignées sur les tailles des blocs (block size)
    Pour s’en assurer, vérifier avec la commande fdisk -lu /dev/sda que les débuts soient bien des multiples de 2048. Si cela n’était pas le cas, redimensionner avec gparted.

     
  • Pas de swap : la RAM ne coûte pas chère et 8 Go c’est amplement suffisant
    Le swap reste nécessaire pour l’hibernation. Mais avec un SSD, la machine démarre en moins de 20 secondes. Alors l’hibernation ne se justifie plus. Si on souhaite quand même avoir un swap (par sécurité, pour l’hibernation…) il est possible d’indiquer de n’utiliser le swap que quand il ne reste plus que 0% de RAM libre en ajoutant la ligne vm.swappiness=0 à la fin du fichier /etc/sysctl.conf.

     
  • Utiliser le système de fichier ext4 avec les options atime,discard
    Attention quand même, l’option discard nécessite que le SSD supporte la technologie TRIM.

     
  • Mettre en RAM les arborescences /tmp et /var
    Sur Ubuntu 12.04, /var/run et /var/lock sont déjà mis en RAM, en parti par le script /etc/init/mounted-var.conf. Donc on peut ajouter à ce script des lignes du style run_migrate /var/log /run/log. Personnellement, j’ai préféré modifier le traditionnel /etc/fstaben ajoutant les lignes suivantes :

    tmpfs /tmp         tmpfs defaults,nosuid,noatime,size=10%,mode=1777       0 0
    tmpfs /var/tmp     tmpfs defaults,nosuid,noatime,size=10%,mode=1777       0 0
    tmpfs /var/log     tmpfs defaults,nosuid,noatime,size=10%,mode=0755,nodev 0 0 
    tmpfs /var/log/apt tmpfs defaults,nosuid,noatime,size=10%                 0 0
    

    Attention, apach n’apprécie que son répertoire /var/log/apache2 soit supprimé à chaque arrêt de la machine (utiliser nginx ou lighttpd à la place).
    Vérifier les point de montage avec la commande df :

    $ df -h
    Sys. fich.     Taille Util. Dispo Uti% Monté sur
    /dev/sda3         92G   76G   12G  87% /
    udev             3,9G  4,0K  3,9G   1% /dev
    tmpfs            789M  108K  789M   1% /tmp
    tmpfs            1,6G  880K  1,6G   1% /run
    none             5,0M     0  5,0M   0% /run/lock
    none             3,9G  212K  3,9G   1% /run/shm
    tmpfs            789M     0  789M   0% /var/tmp
    tmpfs            789M  692K  788M   1% /var/log
    tmpfs            789M   12K  789M   1% /var/log/apt
    

  • Utiliser l’ordonnanceur (scheduler) noop ou deadline
    Le scheduler par défaut, cfq, regroupe les opérations d’entrée/sortie pour optimiser les déplacements de la tête de lecture du disque dur. On peut changer le scheduler à la fin de l’init en ajoutant la ligne  echo noop > /sys/block/sda/queue/scheduler  au script /etc/rc.local.
    Mais je prefère que Linux utilise le bon scheduler dès son démarrage. Pour cela, dans le fichier /etc/default/grub, ajouter le paramètre elevator=noop à la ligne  GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"  (j’ai même supprimé le paramètre splash). Puis mettre à jour la configuration GRUB avec la commande update-grub.
    Au prochain démarrage, vérifier avec  cat /sys/block/sda/queue/scheduler.

     
  • Laisser Firefox gérer son cache
    Firefox gère très bien son cache et n’écrit dans des fichiers que ce qui est nécessaire. Si le cache est encore présent lors du prochain démarrage du PC, alors Firefox réutilisera son cache et sera plus rapide. De plus, Linux conserve en RAM les fichiers tant qu’il y a suffisament de mémoire (sauf quand Firefox force le flush du chache).

     
  • Mesurer la performance de son SSD avec  hdparm -t /dev/sda
    J’ai 477 MB/sec 😉

Sources :

Bien partitioner sa microSD pour Android

Android 4 (ICS) utilise maintenant le protocole MTP pour l’accès à la carte microSD. Et donc l’ordinateur ne requiert plus un accès direct au système de fichiers (USB mass storage). Ce qui permet de choisir un autre système de fichiers bien plus optimisé en latence, charge processeur, ressources mémoire et cycles d’écritures, et par conséquent une consommation électrique moindre 🙂

Le système de fichiers le plus prometteur est Btrfs. Mais celui-ci ne dépasse pas encore le niveau de rapidité et de robustesse de ext4. De plus, les lecteurs (pilotes) ext2/ext3 sont compatibles avec ext4 en lecture seule. Donc ici, nous allons nous concentrer sur ext4.

Afin de paramétrer au mieux notre système de fichiers, nous avons besoin de connaître différentes tailles en octets de la microSD : block d’effacement, page et segment. Comme le constructeur de la carte SD ne communique rarement ces informations nous avons deux choix :

1. Profiter de la veille technologique sur ce sujet :
https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey?action=show&redirect=WorkingGroups%2FKernelConsolidation%2FProjects%2FFlashCardSurvey

2. Mesurer soit même ces paramètres :
https://doukki.net/doku.php?id=wiki:tutoriels:fastbench

Dans mon cas je n’étais pas sûr que ma microSD soit celle de la veille technologique. En effet, cet exemple se base sur la Transcend microSDHC TF 32Go class 10. 32€ chez Mongallet21 en juillet 2012. Au prix du méga-octet c’est moins onéreux qu’une 16Go et qu’une 64Go. De plus, mon GS3 ne supportant pas la norme UFS-1, une microSDXC 64Go UFS-1 ne devrait pas être plus véloce. Plus tard, j’ai appris que la class 4 est mieux adaptée aux accès aléatoires, ce qui est très important pour le système Android. Donc n’achetez pas la même.

J’ai donc opté pour le second choix : obtenir les caractéristiques de la carte SD en mesurant des temps de latence lors des accès à différentes parties de la carte.

L’utilitaire fastbench s’obtient en compilant son code source :

git clone git://git.linaro.org/people/arnd/flashbench.git
cd flashbench
make

Puis, insérer sa carte SD, ne pas la monter et lancer fastbench avec les privilèges root :

$ sudo ./flashbench -a /dev/sdg --blocksize=1024
align 8589934592  pre 848µs    on  998µs   post 962µs    diff 92.9µs
align 4294967296  pre 836µs    on  983µs   post 980µs    diff 75.2µs
align 2147483648  pre 872µs    on  997µs   post 979µs    diff 71.5µs
align 1073741824  pre 849µs    on  996µs   post 978µs    diff 82µs
align 536870912   pre 854µs    on  993µs   post 960µs    diff 86.4µs
align 268435456   pre 820µs    on  978µs   post 994µs    diff 71.3µs
align 134217728   pre 830µs    on  978µs   post 996µs    diff 65.4µs
align 67108864    pre 830µs    on 1.07ms   post 963µs    diff 171µs
align 33554432    pre 837µs    on  978µs   post 980µs    diff 69.8µs
align 16777216    pre 847µs    on 1.07ms   post 991µs    diff 149µs
align  8388608    pre 867µs    on 1.12ms   post 980µs    diff 198µs
align  4194304    pre 872µs    on 1.03ms   post 978µs    diff 107µs
align  2097152    pre 844µs    on 1.09ms   post 953µs    diff 191µs
align  1048576    pre 872µs    on 1.1ms    post 998µs    diff 167µs
align   524288    pre 848µs    on 1.1ms    post 973µs    diff 194µs
align   262144    pre 853µs    on 1.12ms   post 963µs    diff 211µs
align   131072    pre 889µs    on 1.07ms   post 956µs    diff 147µs
align    65536    pre 854µs    on 1.08ms   post 971µs    diff 164µs
align    32768    pre 852µs    on 1.1ms    post 942µs    diff 206µs
align    16384    pre 847µs    on 1.05ms   post 960µs    diff 146µs
align     8192    pre 890µs    on  889µs   post 889µs    diff -60ns
align     4096    pre 891µs    on  919µs   post 891µs    diff 28.1µs
align     2048    pre 975µs    on  973µs   post 962µs    diff 4.06µs

La dernière colonne (diff) permet de déduire la taille block d’effacement (erase block), dans mon cas je dirais plutôt 16Ko. Mais cette valeur n’est pas cohérente avec les différentes données que je trouve sur le net et les faibles valeurs diff des premières lignes me chagrinent.

En lisant le README fournit avec le code source, je comprends que ma carte SD est toute neuve et par conséquent les temps d’accès ne reflètent pas l’utilisation quotidienne. Je décide donc d’écrire sur la totalité de la carte. Un moyen simple est d’écrire un fichier de 32 Go sur la carte SD (plus simple que de réfléchir à une ligne de commande). Les plus gros fichiers sont la représentation brute des disques logiques. Pour déterminer la taille des disques je souhaite utiliser la commande df. Mais cette commande nécessite que les disques soient montés. Avec les distributions modernes, monter les disques se fait simplement via le gestionnaire de fichiers (comme PCManFS) en cliquant sur chaque disque logique (avant c’était encore plus simple avec une seule commande : sudo mount -a). EDIT : il y avait plus simple avec la commande lsblk.

$ df -Th
Sys. fich.     Type     Taille Util. Dispo Uti% Monté sur
/dev/sdb8      btrfs       11G  6,1G  2,2G  74% /
udev           devtmpfs   368M  4,0K  368M   1% /dev
tmpfs          tmpfs      150M  864K  149M   1% /run
none           tmpfs      5,0M     0  5,0M   0% /run/lock
none           tmpfs      375M   80K  375M   1% /run/shm
/dev/sdb1      ext2       7,0G  5,9G  775M  89% /boot
/dev/sde       vfat        11M   11M  304K  98% /media/disk
/dev/sdb3      ext2       7,6G  4,7G  2,5G  66% /media/elive
/dev/sdb5      ext3       9,7G  6,8G  2,5G  74% /media/mandriva
/dev/sdb6      ext2        31G   26G  3,3G  89% /media/backup
/dev/sdd1      vfat       7,9G  3,5G  4,4G  45% /media/LOUP
/dev/sdb7      reiserfs   9,4G  6,8G  2,7G  72% /media/debian
/dev/sda1      reiserfs    75G   70G  5,3G  93% /media/sata80
/dev/sdc5      ext3       2,7G  763M  2,0G  28% /media/home
$ sudo su
# cat /dev/sdb6 > /dev/sdg

Attention à ne pas se tromper de la destination, cela détruit irrémédiablement les données /dev/sdg et sans aucun message d'avertissement. Une erreur de glissement de doigt est vite arrivée...

Cela prend du temps à écrire 31Go... surtout sur un port USB1 !
J'ai regretté de ne pas avoir lancé la commande cat avec time, j'aurais bien aimé savoir combien de temps cela a pris !

On teste à nouveau la carte SD et nous avons maintenant de jolis métriques cohérents :)

# ./flashbench -a /dev/sdg --blocksize=1024
align 8589934592    pre  993µs   on 1.83ms   post 1.02ms   diff 823µs
align 4294967296    pre 1.03ms   on 1.82ms   post 1.01ms   diff 796µs
align 2147483648    pre 1.04ms   on 1.83ms   post 1.03ms   diff 802µs
align 1073741824    pre 1.02ms   on 1.83ms   post  988µs   diff 832µs
align  536870912    pre  999µs   on 1.82ms   post 1ms      diff 818µs
align  268435456    pre 1.03ms   on 1.82ms   post 1.02ms   diff 794µs
align  134217728    pre 1.02ms   on 1.84ms   post 1.03ms   diff 814µs
align   67108864    pre  993µs   on 1.89ms   post 1.03ms   diff 879µs
align   33554432    pre  987µs   on 1.8ms    post 1.02ms   diff 800µs
align   16777216    pre 1.01ms   on 1.84ms   post 1.01ms   diff 824µs
align    8388608    pre 1.01ms   on 1.85ms   post  995µs   diff 847µs
align    4194304    pre 1.03ms   on 1.79ms   post  997µs   diff 779µs
align    2097152    pre 1.02ms   on 1.85ms   post 1.03ms   diff 830µs
align    1048576    pre  990µs   on 1.87ms   post 1ms      diff 873µs
align     524288    pre  980µs   on 1.84ms   post  990µs   diff 851µs
align     262144    pre 1.04ms   on 1.87ms   post 1.03ms   diff 838µs
align     131072    pre  974µs   on 1.8ms    post  998µs   diff 813µs
align      65536    pre 1.03ms   on 1.85ms   post 1.02ms   diff 830µs
align      32768    pre  990µs   on 1.78ms   post  997µs   diff 789µs
align      16384    pre 1.01ms   on 1.07ms   post  994µs   diff 67.6µs
align       8192    pre 1.01ms   on 1.01ms   post  999µs   diff 904ns
align       4096    pre 1.01ms   on 1.01ms   post  980µs   diff 19.2µs
align       2048    pre 1.01ms   on 972µs    post 1.01ms   diff -41283n

D'après la dernière colonne (diff), nous avons un décrochage entre 32Ko, 16Ko et 8Ko. Mais ces valeurs donnent des indications sur la taille de la page, et non pas celle du segment qui est plutôt aux alentours de 4Mo.

Peut-être que notre carte mémoire n'est pas uniformément écrite... Une autre façon d'initialiser notre carte est d'utiliser la commande dd. Ci-dessous, nous réinitialisons à zéro notre carte en écrivant par blocs de 8Mo (10000 blocs). Les blocs de 8Mo permet à la carte SD d'optimiser l'effacement (réinitialisation) des segments avant

$ sudo su
# dd if=/dev/zero of=/dev/sdg bs=8M count=10000 &
# time dd if=/dev/zero of=/dev/sdg bs=8M count=10000&[1] 2982
# ps f
  PID TTY      STAT   TIME COMMAND
 2854 pts/2    S      0:00 sudo su
 2855 pts/2    S      0:00  \_ su
 2863 pts/2    S      5:43      \_ bash
 2982 pts/2    S      0:00          \_ bash
 2983 pts/2    D      0:00          |   \_ dd if=/dev/zero of=/dev/sdg bs=8M count=10000
 2985 pts/2    R+     0:00          \_ ps f
 1217 tty7     Ss+    5:52 /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novt
 1497 tty1     Ss+    0:00 /sbin/getty -8 38400 tty1
 1125 tty6     Ss+    0:00 /sbin/getty -8 38400 tty6
 1118 tty3     Ss+    0:00 /sbin/getty -8 38400 tty3
 1117 tty2     Ss+    0:00 /sbin/getty -8 38400 tty2
 1102 tty5     Ss+    0:00 /sbin/getty -8 38400 tty5
 1097 tty4     Ss+    0:00 /sbin/getty -8 38400 tty4

Le man dd indique que le signal USR1 donne l'état d'avancement :

# kill -USR1 2983
38+0 enregistrements lus
38+0 enregistrements écrits
318767104 octets (319 MB) copiés, 37,0688 s, 8,6 MB/s

Mettons en place un suivit :

# while true; do kill -USR1 2983; sleep 10; done
58+0 enregistrements lus
58+0 enregistrements écrits
486539264 octets (487 MB) copiés, 77,4884 s, 6,3 MB/s
62+0 enregistrements lus
62+0 enregistrements écrits
520093696 octets (520 MB) copiés, 86,7724 s, 6,0 MB/s
67+0 enregistrements lus
67+0 enregistrements écrits
562036736 octets (562 MB) copiés, 98,0405 s, 5,7 MB/s
[...]
92+0 enregistrements lus
92+0 enregistrements écrits
771751936 octets (772 MB) copiés, 155,028 s, 5,0 MB/s
97+0 enregistrements lus
97+0 enregistrements écrits
813694976 octets (814 MB) copiés, 166,393 s, 4,9 MB/s
102+0 enregistrements lus
102+0 enregistrements écrits
855638016 octets (856 MB) copiés, 176,588 s, 4,8 MB/s
106+0 enregistrements lus
106+0 enregistrements écrits
889192448 octets (889 MB) copiés, 185,497 s, 4,8 MB/s
[...]
123+0 enregistrements lus
123+0 enregistrements écrits
1031798784 octets (1,0 GB) copiés, 217,665 s, 4,7 MB/s
[...]
1886+0 enregistrements lus
1886+0 enregistrements écrits
15820914688 octets (16 GB) copiés, 3114,46 s, 5,1 MB/s
1892+0 enregistrements lus
1892+0 enregistrements écrits
15871246336 octets (16 GB) copiés, 3124,21 s, 5,1 MB/s
1898+0 enregistrements lus
1898+0 enregistrements écrits
15921577984 octets (16 GB) copiés, 3134,02 s, 5,1 MB/s
1904+0 enregistrements lus
1904+0 enregistrements écrits
15971909632 octets (16 GB) copiés, 3143,78 s, 5,1 MB/s
[...]
3141+0 enregistrements lus
3141+0 enregistrements écrits
26348617728 octets (26 GB) copiés, 5127,02 s, 5,1 MB/s
[...]
3674+0 enregistrements lus
3674+0 enregistrements écrits
30819745792 octets (31 GB) copiés, 5924 s, 5,2 MB/s
3680+0 enregistrements lus
3680+0 enregistrements écrits
30870077440 octets (31 GB) copiés, 5932,98 s, 5,2 MB/s
3687+0 enregistrements lus
3687+0 enregistrements écrits
30928797696 octets (31 GB) copiés, 5943,5 s, 5,2 MB/s
3694+0 enregistrements lus
3694+0 enregistrements écrits
30987517952 octets (31 GB) copiés, 5953,87 s, 5,2 MB/s
3701+0 enregistrements lus
3701+0 enregistrements écrits
31046238208 octets (31 GB) copiés, 5964,38 s, 5,2 MB/s
3707+0 enregistrements lus
3707+0 enregistrements écrits
31096569856 octets (31 GB) copiés, 5973,37 s, 5,2 MB/s
[...]
3723+0 enregistrements lus
3723+0 enregistrements écrits
31230787584 octets (31 GB) copiés, 5997,32 s, 5,2 MB/s
dd: écriture de «/dev/sdg»: Aucun espace disponible sur le périphérique
3743+0 enregistrements lus
3742+0 enregistrements écrits
31393316864 octets (31 GB) copiés, 6053,2 s, 5,2 MB/s
3743+0 enregistrements lus
3742+0 enregistrements écrits
31393316864 octets (31 GB) copiés, 6053,2 s, 5,2 MB/s

real	100m53.207s
user	0m0.148s
sys	2m21.745s

[1]+  Termine 1               time dd if=/dev/zero of=/dev/sdg bs=8M count=10000

Waou! 100 minutes pour écrire 32Go ! Mon matériel n'est pas non plus une foudre de guerre : le PC date de 2003 et un vieux cadre numérique fait office de lecteur de carte mémoire. D'ailleurs, j'y pense, ce cadre numérique ne supporte peut être pas les capacités de 32 Go...

On vérifie à nouveau avec flashbench :

# ./flashbench -a /dev/sdg --blocksize=1024
align 8589934592 pre 1.01ms	on 1.82ms	post 1.01ms	diff 803µs
align 4294967296 pre 1.01ms	on 1.83ms	post 1.02ms	diff 816µs
align 2147483648 pre 1.03ms	on 1.81ms	post 1.03ms	diff 785µs
align 1073741824 pre 1.01ms	on 1.83ms	post 1.03ms	diff 811µs
align  536870912 pre 1.03ms	on 1.83ms	post 1.05ms	diff 797µs
align  268435456 pre 1.03ms	on 1.81ms	post  995µs	diff 800µs
align  134217728 pre 1.01ms	on 1.82ms	post  994µs	diff 816µs
align   67108864 pre  997µs	on 1.81ms	post  995µs	diff 818µs
align   33554432 pre 1.02ms	on 1.8ms	post  979µs	diff 794µs
align   16777216 pre  974µs	on 1.82ms	post 1.02ms	diff 818µs
align   8388608  pre 1.01ms	on 1.82ms	post 1.03ms	diff 800µs
align   4194304  pre 1.02ms	on 1.79ms	post 1.03ms	diff 768µs
align   2097152  pre 1ms	on 1.8ms	post 1.01ms	diff 792µs
align   1048576  pre 1.01ms	on 1.81ms	post  996µs	diff 808µs
align    524288  pre 1.01ms	on 1.79ms	post  980µs	diff 798µs
align    262144  pre  973µs	on 1.8ms	post 1.01ms	diff 808µs
align    131072  pre 1.03ms	on 1.8ms	post  984µs	diff 793µs
align     65536  pre  987µs	on 1.83ms	post 1ms	diff 836µs
align     32768  pre 1.03ms	on 1.79ms	post  991µs	diff 784µs
align     16384  pre 1.02ms	on 1.07ms	post  993µs	diff 58µs
align      8192  pre 1.02ms	on 1.03ms	post 1.03ms	diff 5.6µs
align      4096  pre 1.02ms	on 992µs	post 1.02ms	diff -29250n
align      2048  pre 1.03ms	on 1.01ms	post 1.05ms	diff -27829n

Pas de surprises, c'est la même chose, et je n'ai pas le courage d'attendre 100 minutes pour écrire des 11111111.

A force de fouiller sur le net, je suis tombé des échanges sur une mailing-liste de Linaro : la carte SD concerné est très proche de la mienne 😉 (Google n'a même pas trouvé, j'ai du chercher à tâtons...)

Image

Boulangerie à Madrid

Les oiseaux picorent les graines de la croûte des pains en exposition devant la boulangerie.

image