Question Quelle est la signification des nombres dans le nom des processus de vidage pour les nouveaux noyaux Linux?


Je cours le noyau 2.6.33.7.

Auparavant, j'utilisais la version 2.6.18.x. Le 2.6.18, les processus de vidage ont été nommés pdflush.

Après la mise à niveau vers 2.6.33.7, les processus de vidage ont le format "flush-:". Par exemple, je vois actuellement un processus de rinçage "flush-8: 32" qui apparaît en haut.

En faisant une recherche google pour essayer de déterminer une réponse à cette question, j'ai vu des exemples de "flush-8: 38", "flush-8: 64" et "flush-253: 0" pour n'en nommer que quelques-uns.

Je comprends ce que le processus de nettoyage lui-même fait, ma question est la suivante: quelle est la signification des chiffres à la fin du nom du processus? Que représentent-ils?

Merci


10
2018-01-07 02:12


origine


Réponses:


Numéros de périphérique utilisés pour identifier les périphériques de bloc. Un thread de noyau peut être généré pour gérer un périphérique particulier.

(Sur l'un de mes systèmes, les périphériques de bloc sont actuellement numérotés comme indiqué ci-dessous. Ils peuvent changer du démarrage à l'amorçage ou du branchement à chaud au branchement à chaud.)

$ grep ^ / sys / class / block / * / dev
/ sys / class / block / dm-0 / dev: 254: 0
/ sys / class / block / dm-1 / dev: 254: 1
/ sys / class / block / dm-2 / dev: 254: 2
/ sys / class / block / dm-3 / dev: 254: 3
/ sys / class / block / dm-4 / dev: 254: 4
/ sys / class / block / dm-5 / dev: 254: 5
/ sys / class / block / dm-6 / dev: 254: 6
/ sys / class / block / dm-7 / dev: 254: 7
/ sys / class / block / dm-8 / dev: 254: 8
/ sys / class / block / dm-9 / dev: 254: 9
/ sys / class / block / loop0 / dev: 7: 0
/ sys / class / block / loop1 / dev: 7: 1
/ sys / class / block / loop2 / dev: 7: 2
/ sys / class / block / loop3 / dev: 7: 3
/ sys / class / block / loop4 / dev: 7: 4
/ sys / class / block / loop5 / dev: 7: 5
/ sys / class / block / loop6 / dev: 7: 6
/ sys / class / block / loop7 / dev: 7: 7
/ sys / class / block / md0 / dev: 9: 0
/ sys / class / block / md1 / dev: 9: 1
/ sys / class / block / sda / dev: 8: 0
/ sys / class / block / sda1 / dev: 8: 1
/ sys / class / block / sda2 / dev: 8: 2
/ sys / class / block / sdb / dev: 8: 16
/ sys / class / block / sdb1 / dev: 8: 17
/ sys / class / block / sdb2 / dev: 8: 18
/ sys / class / block / sdc / dev: 8: 32
/ sys / class / block / sdc1 / dev: 8: 33
/ sys / class / block / sdc2 / dev: 8: 34
/ sys / class / block / sdd / dev: 8: 48
/ sys / class / block / sdd1 / dev: 8: 49
/ sys / class / block / sdd2 / dev: 8: 50
/ sys / class / block / sde / dev: 8: 64
/ sys / class / block / sdf / dev: 8: 80
/ sys / class / block / sdg / dev: 8: 96
/ sys / class / block / sdh / dev: 8: 112
/ sys / class / block / sdi / dev: 8: 128
/ sys / class / block / sr0 / dev: 11: 0
/ sys / class / block / sr1 / dev: 11: 1
/ sys / class / block / sr2 / dev: 11: 2

8
2018-01-07 05:11



Vous devriez également être en mesure de comprendre cela en recherchant ces nombres dans / proc / self / mountinfo, par exemple:

$ grep 8:32 /proc/self/mountinfo
25 22 8:32 / /var rw,relatime - ext4 /dev/mapper/sysvg-var rw,barrier=1,data=ordered

Cela a l'avantage de travailler avec nfs:

$ grep 0:73 /proc/self/mountinfo
108 42 0:73 /foo /mnt/foo rw,relatime - nfs host.domain.com:/volume/path rw, ...

Notez que les données que j'ai incluses ici sont fabriquées, mais le mécanisme fonctionne correctement.


7
2018-02-16 17:02