Je suis en train de compiler thrash
<http://www.csc.liv.ac.uk/~greg/thrash/>
sur MacOSX afin de tester une baie RAID qui présente des défauts.
A part le fait que les flags O_LARGEFILE et O_DIRECT ne sont pas
supportés par BSD (je les ai définis à 0x0), tout se passe bien, jusque
et y compris l'ouverture du device, /dev/disk2s2 dans mon cas.
Par contre j'obtiens le message d'erreur "ENOTTY Inappropriate ioctl for
device" lorsque je tente un bête lseek.
Oserais-je imagine que lseek sur un device est supporté sous Linux mais
pas sous BSD ?
Merci,
--
Xav
Disponible au 01/04/2010
<http://www.xavierhumbert.net/perso/CV2.html>
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
lusenet
Le Fri, 29 Jan 2010 12:29:09 +0100, Xavier a écrit :
Je suis en train de compiler thrash <http://www.csc.liv.ac.uk/~greg/thrash/> sur MacOSX afin de tester une baie RAID qui présente des défauts.
A part le fait que les flags O_LARGEFILE et O_DIRECT ne sont pas supportés par BSD (je les ai définis à 0x0), tout se passe bien, jusque et y compris l'ouverture du device, /dev/disk2s2 dans mon cas.
Par contre j'obtiens le message d'erreur "ENOTTY Inappropriate ioctl for device" lorsque je tente un bête lseek.
Oserais-je imagine que lseek sur un device est supporté sous Linux mais pas sous BSD ?
Pour pouvoir faire un "lseek()" sur un device, il faut en général utiliser le device en mode "character", pas celui en mode bloc. La première colonne affichée par "ls -l /dev/$DEVICE" indique le type de device.
Je ne connais pas la différence de nommage sur MacOSX, sur OpenBSD par exemple, c'est "/dev/r$DEVICE" au lieu de "/dev/$DEVICE" ('r' ajouté avant le nom du disque).
Loïc.
Le Fri, 29 Jan 2010 12:29:09 +0100, Xavier a écrit :
Je suis en train de compiler thrash
<http://www.csc.liv.ac.uk/~greg/thrash/>
sur MacOSX afin de tester une baie RAID qui présente des défauts.
A part le fait que les flags O_LARGEFILE et O_DIRECT ne sont pas
supportés par BSD (je les ai définis à 0x0), tout se passe bien, jusque
et y compris l'ouverture du device, /dev/disk2s2 dans mon cas.
Par contre j'obtiens le message d'erreur "ENOTTY Inappropriate ioctl for
device" lorsque je tente un bête lseek.
Oserais-je imagine que lseek sur un device est supporté sous Linux mais
pas sous BSD ?
Pour pouvoir faire un "lseek()" sur un device, il faut en général
utiliser le device en mode "character", pas celui en mode bloc.
La première colonne affichée par "ls -l /dev/$DEVICE" indique le type
de device.
Je ne connais pas la différence de nommage sur MacOSX, sur OpenBSD par
exemple, c'est "/dev/r$DEVICE" au lieu de "/dev/$DEVICE" ('r' ajouté
avant le nom du disque).
Le Fri, 29 Jan 2010 12:29:09 +0100, Xavier a écrit :
Je suis en train de compiler thrash <http://www.csc.liv.ac.uk/~greg/thrash/> sur MacOSX afin de tester une baie RAID qui présente des défauts.
A part le fait que les flags O_LARGEFILE et O_DIRECT ne sont pas supportés par BSD (je les ai définis à 0x0), tout se passe bien, jusque et y compris l'ouverture du device, /dev/disk2s2 dans mon cas.
Par contre j'obtiens le message d'erreur "ENOTTY Inappropriate ioctl for device" lorsque je tente un bête lseek.
Oserais-je imagine que lseek sur un device est supporté sous Linux mais pas sous BSD ?
Pour pouvoir faire un "lseek()" sur un device, il faut en général utiliser le device en mode "character", pas celui en mode bloc. La première colonne affichée par "ls -l /dev/$DEVICE" indique le type de device.
Je ne connais pas la différence de nommage sur MacOSX, sur OpenBSD par exemple, c'est "/dev/r$DEVICE" au lieu de "/dev/$DEVICE" ('r' ajouté avant le nom du disque).
Loïc.
xavier
Loic Tortay wrote:
Je ne connais pas la différence de nommage sur MacOSX, sur OpenBSD par exemple, c'est "/dev/r$DEVICE" au lieu de "/dev/$DEVICE" ('r' ajouté avant le nom du disque).
C'est pareil sous MacOSX (à la base, c'est un mix de Free, Net et Open, par dessus un noyau Mach)
Mais je viens de tester avec /dev/rdisk2s2 ou même /dev/rdisk2 en argument, ça ne change malheureusement rien...
Merci quand même,
-- Xav Disponible au 01/04/2010 <http://www.xavierhumbert.net/perso/CV2.html>
Loic Tortay <lusenet@bougon.net.invalid> wrote:
Je ne connais pas la différence de nommage sur MacOSX, sur OpenBSD par
exemple, c'est "/dev/r$DEVICE" au lieu de "/dev/$DEVICE" ('r' ajouté
avant le nom du disque).
C'est pareil sous MacOSX (à la base, c'est un mix de Free, Net et Open,
par dessus un noyau Mach)
Mais je viens de tester avec /dev/rdisk2s2 ou même /dev/rdisk2 en
argument, ça ne change malheureusement rien...
Merci quand même,
--
Xav
Disponible au 01/04/2010
<http://www.xavierhumbert.net/perso/CV2.html>
Je ne connais pas la différence de nommage sur MacOSX, sur OpenBSD par exemple, c'est "/dev/r$DEVICE" au lieu de "/dev/$DEVICE" ('r' ajouté avant le nom du disque).
C'est pareil sous MacOSX (à la base, c'est un mix de Free, Net et Open, par dessus un noyau Mach)
Mais je viens de tester avec /dev/rdisk2s2 ou même /dev/rdisk2 en argument, ça ne change malheureusement rien...
Merci quand même,
-- Xav Disponible au 01/04/2010 <http://www.xavierhumbert.net/perso/CV2.html>
xavier
Xavier wrote:
Mais je viens de tester avec /dev/rdisk2s2 ou même /dev/rdisk2 en argument, ça ne change malheureusement rien...
Cependant, j'ai trouvé un workaround pour le premier lseek
Pour aller *effectivement* lire un block défini, lseek échoue toujours. Et je n'ai pas vu de paramètre à ioctl qui permette ça (dans <sys/disk.h>)
Bonjour Xavier,
Etes-vous sûr de ne pas être victime de ce qui est décrit ici:
http://en.wikipedia.org/wiki/Not_a_typewriter
Pour ma part je trouve très curieux qu'un appel système comme lseek() vous injurie en vous disant qu'il ne peut pas s'exécuter parce que l'opération ne porte pas sur un TTY ! ;-) C'est plutôt l'inverse qui ferait râler lseek() normalement !
Cordialement,
Bruno
Xavier wrote:
Cependant, j'ai trouvé un workaround pour le premier lseek
Pour aller *effectivement* lire un block défini, lseek échoue toujours. Et
je n'ai pas vu de paramètre à ioctl qui permette ça (dans <sys/disk.h>)
Bonjour Xavier,
Etes-vous sûr de ne pas être victime de ce qui est décrit ici:
http://en.wikipedia.org/wiki/Not_a_typewriter
Pour ma part je trouve très curieux qu'un appel système comme lseek()
vous injurie en vous disant qu'il ne peut pas s'exécuter parce que
l'opération ne porte pas sur un TTY ! ;-) C'est plutôt l'inverse qui
ferait râler lseek() normalement !
Pour aller *effectivement* lire un block défini, lseek échoue toujours. Et je n'ai pas vu de paramètre à ioctl qui permette ça (dans <sys/disk.h>)
Bonjour Xavier,
Etes-vous sûr de ne pas être victime de ce qui est décrit ici:
http://en.wikipedia.org/wiki/Not_a_typewriter
Pour ma part je trouve très curieux qu'un appel système comme lseek() vous injurie en vous disant qu'il ne peut pas s'exécuter parce que l'opération ne porte pas sur un TTY ! ;-) C'est plutôt l'inverse qui ferait râler lseek() normalement !
Cordialement,
Bruno
xavier
Bruno Tréguier wrote:
Etes-vous sûr de ne pas être victime de ce qui est décrit ici:
http://en.wikipedia.org/wiki/Not_a_typewriter
Ca y ressemble. Et c'est curieux, parce que, sous Linux, lseek marche sur un device (block ou charachter, d'ailleurs)
Je vais voir si j'ai les versions de debug des librairies pour tracer ce qui se passe exactement...
-- Xav Disponible au 01/04/2010 <http://www.xavierhumbert.net/perso/CV2.html>
Bruno Tréguier <bruno.treguier_at_shom.fr@nullepart.invalid> wrote:
Etes-vous sûr de ne pas être victime de ce qui est décrit ici:
http://en.wikipedia.org/wiki/Not_a_typewriter
Ca y ressemble. Et c'est curieux, parce que, sous Linux, lseek marche
sur un device (block ou charachter, d'ailleurs)
Je vais voir si j'ai les versions de debug des librairies pour tracer ce
qui se passe exactement...
--
Xav
Disponible au 01/04/2010
<http://www.xavierhumbert.net/perso/CV2.html>
Etes-vous sûr de ne pas être victime de ce qui est décrit ici:
http://en.wikipedia.org/wiki/Not_a_typewriter
Ca y ressemble. Et c'est curieux, parce que, sous Linux, lseek marche sur un device (block ou charachter, d'ailleurs)
Je vais voir si j'ai les versions de debug des librairies pour tracer ce qui se passe exactement...
-- Xav Disponible au 01/04/2010 <http://www.xavierhumbert.net/perso/CV2.html>
Éric Lévénez
Le 29/01/10 15:45, Xavier a écrit :
devsize=lseek(fd, 0, SEEK_END);
Je viens de tester des lseek (SEEK_SET...) sur un système de fichiers sous Mac OS X 10.6 (64 bits) sans soucis.
Le code lseek avec SEEK_END retourne 0 et non la taille du système de fichiers, mais cela n'a rien de surprenant. Pour avoir les informations sur un fichier c'est stat, et sur un système de fichiers c'est statfs. Le coup du lseek pour avoir une taille n'est pas propre de toute façon. Les vieux codes qui semblent marcher et qui marchent par hasard sont légions.
Si ton code n'a pas les bons includes, il peut compiler, mais ne pas marcher, en particulier parce que la taille "offset" est un 64 bits. Est-ce que le code suivant te donne toujours une erreur lseek, ou 0 comme chez moi ?
devsize = lseek(fd, (off_t)0, SEEK_END);
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 29/01/10 15:45, Xavier a écrit :
devsize=lseek(fd, 0, SEEK_END);
Je viens de tester des lseek (SEEK_SET...) sur un système de fichiers
sous Mac OS X 10.6 (64 bits) sans soucis.
Le code lseek avec SEEK_END retourne 0 et non la taille du système de
fichiers, mais cela n'a rien de surprenant. Pour avoir les informations
sur un fichier c'est stat, et sur un système de fichiers c'est statfs.
Le coup du lseek pour avoir une taille n'est pas propre de toute façon.
Les vieux codes qui semblent marcher et qui marchent par hasard sont
légions.
Si ton code n'a pas les bons includes, il peut compiler, mais ne pas
marcher, en particulier parce que la taille "offset" est un 64 bits.
Est-ce que le code suivant te donne toujours une erreur lseek, ou 0
comme chez moi ?
devsize = lseek(fd, (off_t)0, SEEK_END);
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Je viens de tester des lseek (SEEK_SET...) sur un système de fichiers sous Mac OS X 10.6 (64 bits) sans soucis.
Le code lseek avec SEEK_END retourne 0 et non la taille du système de fichiers, mais cela n'a rien de surprenant. Pour avoir les informations sur un fichier c'est stat, et sur un système de fichiers c'est statfs. Le coup du lseek pour avoir une taille n'est pas propre de toute façon. Les vieux codes qui semblent marcher et qui marchent par hasard sont légions.
Si ton code n'a pas les bons includes, il peut compiler, mais ne pas marcher, en particulier parce que la taille "offset" est un 64 bits. Est-ce que le code suivant te donne toujours une erreur lseek, ou 0 comme chez moi ?
devsize = lseek(fd, (off_t)0, SEEK_END);
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
xavier
Éric Lévénez wrote:
Est-ce que le code suivant te donne toujours une erreur lseek, ou 0 comme chez moi ?
devsize = lseek(fd, (off_t)0, SEEK_END);
Je sépare les tâches : Usenet sur le MacBookPro devant la télé au RDC, et XCode est à l'étage :-) Je te tiens au courant.
Merci Éric.
-- XAv Disponible au 01/06/2010 <http://www.xavierhumbert.net/perso/CV2.html>
Éric Lévénez <usenet@levenez.com> wrote:
Est-ce que le code suivant te donne toujours une erreur lseek, ou 0
comme chez moi ?
devsize = lseek(fd, (off_t)0, SEEK_END);
Je sépare les tâches : Usenet sur le MacBookPro devant la télé au RDC,
et XCode est à l'étage :-) Je te tiens au courant.
Merci Éric.
--
XAv
Disponible au 01/06/2010
<http://www.xavierhumbert.net/perso/CV2.html>
