<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Cap Data Team SGBD Blog : Oracle, SQL Server, MySQL, Sybase... &#187; Sybase</title>
	<atom:link href="http://blog.capdata.fr/index.php/tag/sybase/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.capdata.fr</link>
	<description>Le blog technique sur les bases de données de CAP DATA Consulting</description>
	<lastBuildDate>Wed, 01 Feb 2012 17:21:53 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Direct i/o, dsync on/off, raw device</title>
		<link>http://blog.capdata.fr/index.php/sybase-ase-direct-io-dsync-onoff-raw-device/</link>
		<comments>http://blog.capdata.fr/index.php/sybase-ase-direct-io-dsync-onoff-raw-device/#comments</comments>
		<pubDate>Thu, 18 Jun 2009 15:20:11 +0000</pubDate>
		<dc:creator>David BAFFALEUF</dc:creator>
				<category><![CDATA[Sybase]]></category>
		<category><![CDATA[directio]]></category>
		<category><![CDATA[dsync]]></category>
		<category><![CDATA[kernel]]></category>
		<category><![CDATA[linux]]></category>

		<guid isPermaLink="false">https://www.alldb.fr/blogs/?p=148</guid>
		<description><![CDATA[Il y a depuis 2 ans et encore aujourd&#8217;hui un gros débat sur l&#8217;avenir du direct IO sur Linux dans la communauté des développeurs kernel (cf post Linus http://lkml.org/lkml/2007/1/10/233) . L&#8217;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 [...]]]></description>
			<content:encoded><![CDATA[<p>Il y a depuis 2 ans et encore aujourd&#8217;hui un gros débat sur l&#8217;avenir du direct IO sur Linux dans la communauté des développeurs kernel (cf post Linus <a title="LKML.org" href="http://lkml.org/lkml/2007/1/10/233"><em>http://lkml.org/lkml/2007/1/10/233</em></a>) . L&#8217;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):</p>
<p><strong>WARNING</strong><br />
<em>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-<br />
date for removal from future releases.</em></p>
<p>Le bénéfice du raw device n&#8217;est pas nouveau, que ce soit pour Adaptive Server ou Oracle, le fait d&#8217;écrire directement sur la partition brute a deux avantages majeurs pour les SGBD:<br />
1 &#8211; Ca va plus vite.<br />
2 &#8211; Ca garantit que ce que l&#8217;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&#8217;indexes, et ne doit pas se reposer sur le système pour ça.</p>
<p>A partir du moment où le raw device cesse d&#8217;être supporté, on va devoir écrire dans un fichier, et qui dit écriture dans un fichier sous UNIX/Linux dit écriture bufferisée. C&#8217;est là où le critère 2 n&#8217;est plus garanti.</p>
<p>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&#8217;ouverture du fichier, le plus souvent open(), sous la forme de flags: O_DIRECT, O_DSYNC ou O_ASYNC.</p>
<p>A travers Adaptive Server, ces arguments seront manipulés lors de la création de devices avec la commande disk init:</p>
<pre>disk init name='PERFSTATS_data01', physname='/sybase_data/ASE1502/userdb/PERFSTATS_data01.dat',
size=512000,
directio=true</pre>
<p>ou</p>
<pre>disk init name='PERFSTATS_data01', physname='/sybase_data/ASE1502/userdb/PERFSTATS_data01.dat',
size=512000,
dsync=true</pre>
<p>On ne peut pas utiliser à la fois directio=true et dsync=true pour le même device, les options sont mutuellement exclusives.</p>
<p><strong>DIRECTIO</strong>:<br />
Lorsque directio est à true, le fichier PERFSTATS_data01.dat sera ouvert avec le flag O_DIRECT:</p>
<pre>open("/sybase_log/ASE1502/userdb/PERFSTATS_data01.dat", O_RDWR|O_SYNC|O_DIRECT|O_LARGEFILE) = 17</pre>
<p>Lorsque la primitive d&#8217;écriture est invoquée (write(), aiowrite()), l&#8217;é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.</p>
<p><strong>DSYNC:</strong><br />
Lorsque dsync est à true, le fichier PERFSTATS_data01.dat sera ouvert avec le flag O_DSYNC:</p>
<pre>open("/sybase_log/ASE1502/userdb/PERFSTATS_data01.dat", O_RDWR|O_DSYNC|O_LARGEFILE) = 17</pre>
<p>Lorsque dsync est à false, le fichier PERFSTATS_data01.dat sera ouvert avec le flag O_ASYNC:</p>
<pre>open("/sybase_log/ASE1502/userdb/PERFSTATS_data01.dat", O_RDWR|O_ASYNC|O_LARGEFILE) = 17</pre>
<p>Lorsque la primitive d&#8217;écriture est invoquée, l&#8217;é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.<br />
<em><strong>- dsync=true</strong></em>: alors le flag O_DSYNC est passé à open(). Ce flag garantit que write() reste en attente tant que les données n&#8217;ont pas été synchronisées sur disque.<br />
<em><strong>- dsync=false:</strong></em> alors le flag O_ASYNC est passé à open(). Ce flag indique que write() rend la main une fois l&#8217;écriture bufferisée mais AVANT la synchronisation sur disque, ce qui ne garantit pas notre critère 2.</p>
<p>On recommandera toujours de mettre dsync=true pour les devices de données et de journaux pour avoir la garantie d&#8217;écriture stabilisée, et dsync=false pour les devices tempdb pour favoriser la perf.</p>
<p><strong>- Avantages / Inconvénients pour le DSYNC: </strong><br />
<em><strong>Avantages</strong></em>: c&#8217;est complètement supporté par les file system.<br />
<em><strong>Inconvénients</strong></em>: C&#8217;est moins performant en écriture.</p>
<p><strong>- Avantages / Inconvénients pour le DIRECTIO: </strong><br />
<em><strong>Avantages</strong></em>: c&#8217;est comme du raw device, sauf que c&#8217;est dans un fichier. C&#8217;est même plus efficace en lecture.<br />
<em><strong>Inconvénients</strong></em>: il faut que le filesystem le supporte (c&#8217;est le cas pour ext3), et d&#8217;après Linus l&#8217;implémentation de directio au niveau du kernel est épouvantable. Le problème c&#8217;est que ce qu&#8217;il indique comme contournement à destination des développeurs ASE (Wim Ten Have et Dave Wein en tête) n&#8217;est pas vraiment applicable.</p>
<p>Pas de doute, le DIRECTIO reste la meilleure option.  Ce sera sûrement réécrit un jour, mais pour l&#8217;instant on n&#8217;a pas trouvé mieux.</p>
<p>Un dernier mot sur le dsync=true sur les noyaux 2.6+, l&#8217;écriture asynchrone se transforme en écriture synchrone et les perfs chutent  <img src='http://blog.capdata.fr/wp-includes/images/smilies/icon_sad.gif' alt=':-(' class='wp-smiley' /> (( . Il faut vraiment utiliser directio sur les noyaux récents. Ce sera peut être le sujet d&#8217;un prochain post sur ASE.</p>
<p>A+ [ David B. ]</p>
<p> <script type="text/javascript" src="http://tcr.tynt.com/javascripts/Tracer.js?user=d4FlbGI04r35lZadbi-bpO"></script><strong>Continuez votre lecture sur le blog :</strong>
<ul class="similar-posts">
<li><a href="http://blog.capdata.fr/index.php/journees-sql-server-1213-decembre-suite/" rel="bookmark" title="27 décembre 2011">Journées SQL Server 12/13 décembre (suite)</a> (David BAFFALEUF) [SQL Server]</li>
<li><a href="http://blog.capdata.fr/index.php/oracle-les-rpms-et-les-dependances-avec-yum/" rel="bookmark" title="6 novembre 2009">Oracle, les Rpms plus de souci avec YUM</a> (Thierry GASCARD) [Oracle]</li>
<li><a href="http://blog.capdata.fr/index.php/creation-d%e2%80%99une-physical-standby-database/" rel="bookmark" title="8 mars 2010">Création d’un Dataguard physique</a> (Guillaume DEFENDINI) [Oracle]</li>
<li><a href="http://blog.capdata.fr/index.php/bench-avec-netapp-datacore-esx/" rel="bookmark" title="26 avril 2011">Bench avec NetApp / Datacore / ESX</a> (David BAFFALEUF) [SQL Server]</li>
<li><a href="http://blog.capdata.fr/index.php/consistence-des-ecritures-avec-sata/" rel="bookmark" title="13 mars 2011">Consistence des écritures avec SATA</a> (David BAFFALEUF) [Operating SystemSQL Server]</li>
</ul>
<p><!-- Similar Posts took 3.271 ms -->
<div class="tweetmeme_button" style="float: right; margin-left: 10px;">
			<a href="http://api.tweetmeme.com/share?url=http%3A%2F%2Fblog.capdata.fr%2Findex.php%2Fsybase-ase-direct-io-dsync-onoff-raw-device%2F"><br />
				<img src="http://api.tweetmeme.com/imagebutton.gif?url=http%3A%2F%2Fblog.capdata.fr%2Findex.php%2Fsybase-ase-direct-io-dsync-onoff-raw-device%2F&amp;style=normal&amp;b=2" height="61" width="50" /><br />
			</a>
		</div>
]]></content:encoded>
			<wfw:commentRss>http://blog.capdata.fr/index.php/sybase-ase-direct-io-dsync-onoff-raw-device/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
	</channel>
</rss>

