Direct i/o, dsync on/off, raw device

Il y a depuis 2 ans et encore aujourd’hui un gros débat sur l’avenir du direct IO sur Linux dans la communauté des développeurs kernel (cf post Linus https://lkml.org/lkml/2007/1/10/233) . L’avenir du raw device lui ne se pose même plus puisque Red Hat ne le supporte plus que du bout des doigts (cf la manpage de raw en RHEL5):

WARNING
Although Linux includes support for rawio, it is now a deprecated interface. If your application performs device access using this interface, Red Hat encourages you to modify your application to open the block device with the O_DIRECT flag. The rawio interface will exist for the life of Red Hat Enterprise Linux 5, but is a candi-
date for removal from future releases.

Le bénéfice du raw device n’est pas nouveau, que ce soit pour Adaptive Server ou Oracle, le fait d’écrire directement sur la partition brute a deux avantages majeurs pour les SGBD:
1 – Ca va plus vite.
2 – Ca garantit que ce que l’on écrit va bien sur le disque et non dans un buffer en mémoire. En effet, le système de base de données gère lui-même la bufferisation de ses pages de données et d’indexes, et ne doit pas se reposer sur le système pour ça.

A partir du moment où le raw device cesse d’être supporté, on va devoir écrire dans un fichier, et qui dit écriture dans un fichier sous UNIX/Linux dit écriture bufferisée. C’est là où le critère 2 n’est plus garanti.

Il reste alors deux solutions qui vont nous permettre de garantir celà: DIRECTIO ou DSYNC. Ce sont en fait des arguments qui vont être passés à la primitive d’ouverture du fichier, le plus souvent open(), sous la forme de flags: O_DIRECT, O_DSYNC ou O_ASYNC.

A travers Adaptive Server, ces arguments seront manipulés lors de la création de devices avec la commande disk init:

disk init name='PERFSTATS_data01', physname='/sybase_data/ASE1502/userdb/PERFSTATS_data01.dat',
size=512000,
directio=true

ou

disk init name='PERFSTATS_data01', physname='/sybase_data/ASE1502/userdb/PERFSTATS_data01.dat',
size=512000,
dsync=true

On ne peut pas utiliser à la fois directio=true et dsync=true pour le même device, les options sont mutuellement exclusives.

DIRECTIO:
Lorsque directio est à true, le fichier PERFSTATS_data01.dat sera ouvert avec le flag O_DIRECT:

open("/sybase_log/ASE1502/userdb/PERFSTATS_data01.dat", O_RDWR|O_SYNC|O_DIRECT|O_LARGEFILE) = 17

Lorsque la primitive d’écriture est invoquée (write(), aiowrite()), l’écriture va directement sur le disque. Donc sémantiquement équivalent à ce que donne une écriture sur un raw device, à la fois en termes de performances et de garantie.

DSYNC:
Lorsque dsync est à true, le fichier PERFSTATS_data01.dat sera ouvert avec le flag O_DSYNC:

open("/sybase_log/ASE1502/userdb/PERFSTATS_data01.dat", O_RDWR|O_DSYNC|O_LARGEFILE) = 17

Lorsque dsync est à false, le fichier PERFSTATS_data01.dat sera ouvert avec le flag O_ASYNC:

open("/sybase_log/ASE1502/userdb/PERFSTATS_data01.dat", O_RDWR|O_ASYNC|O_LARGEFILE) = 17

Lorsque la primitive d’écriture est invoquée, l’écriture sera bufferisée mais en fonction de la valeur passée à disk init (true ou false), certains éléments vont être synchronisés sur disque avant que aiowrite() ne revienne au programme appelant.
– dsync=true: alors le flag O_DSYNC est passé à open(). Ce flag garantit que write() reste en attente tant que les données n’ont pas été synchronisées sur disque.
– dsync=false: alors le flag O_ASYNC est passé à open(). Ce flag indique que write() rend la main une fois l’écriture bufferisée mais AVANT la synchronisation sur disque, ce qui ne garantit pas notre critère 2.

On recommandera toujours de mettre dsync=true pour les devices de données et de journaux pour avoir la garantie d’écriture stabilisée, et dsync=false pour les devices tempdb pour favoriser la perf.

– Avantages / Inconvénients pour le DSYNC:
Avantages: c’est complètement supporté par les file system.
Inconvénients: C’est moins performant en écriture.

– Avantages / Inconvénients pour le DIRECTIO:
Avantages: c’est comme du raw device, sauf que c’est dans un fichier. C’est même plus efficace en lecture.
Inconvénients: il faut que le filesystem le supporte (c’est le cas pour ext3), et d’après Linus l’implémentation de directio au niveau du kernel est épouvantable. Le problème c’est que ce qu’il indique comme contournement à destination des développeurs ASE (Wim Ten Have et Dave Wein en tête) n’est pas vraiment applicable.

Pas de doute, le DIRECTIO reste la meilleure option. Ce sera sûrement réécrit un jour, mais pour l’instant on n’a pas trouvé mieux.

Un dernier mot sur le dsync=true sur les noyaux 2.6+, l’écriture asynchrone se transforme en écriture synchrone et les perfs chutent :-((( . Il faut vraiment utiliser directio sur les noyaux récents. Ce sera peut être le sujet d’un prochain post sur ASE.

A+ [ David B. ]

Continuez votre lecture sur le blog :

• I/O asynchrones (épisode 1) (David Baffaleuf) [Operating SystemSQL Server]
• Partitionnement sémantique (Capdata team) [Sybase]
• Consistence des écritures avec SATA (David Baffaleuf) [Operating SystemSQL Server]
• Installation ASM sur SUSE 10 en 64 Bits avec multipathing (EMC Powerpath) (Capdata team) [OracleVintage]
• Pas de la tarte (David Baffaleuf) [Operating SystemSQL Server]