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]
Hello,
Petite précision de Dave Wein de l’engineering concernant le problème de dysnc=true sur les noyaux 2.6:
“Hi David. When doing async i/o to files in the 2.6 kernel, the OS will silently convert your i/o to synchronous unless direct i/o is used. With async i/o we use the io_submit() system call. This is supposed to post the i/o to a queue that the OS handles, with the call returning immediately to ASE. But if direct i/o isn’t used, io_submit() will not return until the I/O actually completes. If you only have one active user, then no big deal. But if ASE has other work to do this can really hurt performance. AFAIK this is simply as aspect of the linux design and will not be changed.”
A+ Flaming-9
Hello Alain,
Il n’y a rien d’officiel à ce que je sache. Il suffit de lire l’install guide ou le release bulletin de la 15.5 sur Linux, pour voir que rien n’a changé au niveau de ces documents depuis la 15 GA, en tous cas du point de vue du raw device.
Il ne reste que cette discussion sur le blog de Dave Wein il y a 2 ans (http://blogs.sybase.com/dwein/?p=327).
David B.