Solaris mon amour

Comment vérifier le mode d'accès directio sur nos fichiers ? Confronté récemment à cette question, je vous livre ici une des manières d'y répondre. A noter l'utilisation d'UFS dans mon cas.

Il existe deux implémentations du directio pour UFS :

• Option de montage du système de fichiers
• Modification du flag de l'inode pour un fichier ouvert

La 1er méthode est assez simple à vérifier alors que la 2ème si vous n'êtes pas en train de vérifier l'appel ioctl() au moment ou celui-ci se produit il est plus difficile de le vérifier (je vous renvois à l'article suivant pour plus de précision). Reste la possibilité d'utiliser dtrace mais encore faut'il que le fichier soit accéder pour le savoir.

Bon passons un peu aux manipulations... Avec dtrace on peut utiliser la ligne suivante et attendre (longtemps... très longtemps)

# dtrace -qn fbt:ufs:directio_start:entry { printf("%d %s", pid, stringof(args[1]-›i_vnode-›v_path)); }
21350 /zones/zone01/root/ZONE01/oradata13/XXXG02/xxxg02_crontrol_02.ctl
21350 /zones/zone01/root/ZONE01/oradata13/XXXG02/xxxg02_crontrol_01.ctl
^C

Ici le process 21350 accède aux fichiers control* avec le mode d'accès directio. Vérifions maintenant dans le kernel ce qui s'y passe vraiment.

# sudo mdb -k
Loading modules: [ unix genunix specfs dtrace zfs sd pcisch ssd fcp fctl mpt emlxs ip mpt_sas hook neti sctp arp usba s1394 wrsm nca lofs md cpc wrsmd fcip random crypto logindmux ptm ufs sppp nfs ipc ]
> 0t21350::pid2proc
3021bbcd3e0
 3021bbcd3e0::pfiles !grep control
 256  REG 000003009dacc2c0 /zones/zone01/root/ZONE01/oradata13/XXXG02/xxxg02_control_01.ctl
 257  REG 000003006520e300 /zones/zone01/root/ZONE01/oradata13/XXXG02/xxxg02_control_02.ctl

> 000003009dacc2c0::print vnode_t

{
    v_lock = {
        _opaque = [ 0 ]
    }
    v_flag = 0x10000
    v_count = 0x5
    v_data = 0x30127d14d10
    v_vfsp = 0x60063e12040
    v_stream = 0
    v_type = 1 (VREG)
    v_rdev = 0xffffffffffffffff
    v_vfsmountedhere = 0
    v_op = 0x6006883ed80
    v_pages = 0
    v_npages = 0
    v_msnpages = 0
    v_scanfront = 0
    v_scanback = 0
    v_filocks = 0x3002740bd40
    v_shrlocks = 0
    v_nbllock = {
        _opaque = [ 0 ]
    }
    v_cv = {
        _opaque = 0
    }
    v_locality = 0
    v_femhead = 0
    v_path = 0x300adca6020 "/zones/zone01/root/ZONE01/oradata13/XXXG02/xxxg02_control_01.ctl"
    v_rdcnt = 0x4
    v_wrcnt = 0x4
    v_mmap_read = 0
    v_mmap_write = 0
    v_mpssdata = 0
    v_scantime = 0
    v_mset = 0
    v_msflags = 0
    v_msnext = 0                     
    v_msprev = 0
    v_mslock = {
        _opaque = [ 0 ]
    }
}

Comme évoqué plus haut, il y a deux implémentations possibles pour le directio. Soit le montage du système de fichiers posséde l'option directio (man mount_ufs), soit le flag de l'inode (voir ufs_inode.h).

Vérifions l'une et l'autre dans le kernel :

> 0x60063e12040::fsinfo -v
            VFSP FS              MOUNT
0000060063e12040 ufs             /zones/zone01/root/ZONE01/oradata13
              R: /dev/vx/dsk/zone01/oradata13
              O: rw,intr,largefiles,logging,noquota,xattr,nodfratime,onerror=panic

Nous voyons dans les options de montage qu'il ne sagit pas de la 1er méthode d'implémentation. Voyons la suivante :

> 0x30127d14d10::print inode_t !grep i_flag
    i_flag = 0x4260

Le flag pour cette inode possède bien le masque directio (0x4000). Suite à l'ouverture du fichier open(), l'application (ici une base de données Oracle) a modifié le mode d'accès directio par l'appel ioctl().

A vous de jouer pour vérifier directement dans le kernel, le mode d'accès directio à tous vos fichiers. Dans un prochain article je reviendrai sur ce mode (son fonctionnement, pourquoi l'utiliser, exemple d'un problème de performance).