Je suis actuellement sous FreeBSD 5.1-RELEASE en test intensif depuis
maintenant une semaine. Jusqu'ici, voici les problèmes que j'ai rencontrés
:
* Samba sous KDE (3.1.2) : le protocole "smb://" fonctionne, jusqu'à un
transfert effectif de fichier, au bout d'une quantité aléatoire (parfois
nulle) de données transférées, le débit tombe à 0 ("stalled"). Etant
incapable de résoudre le problème (Note : faire exactement la même chose
sous Linux Slackware 9.1, KDE 3.1.4, fonctionne parfaitement), je l'ai
contourné en montant le système de fichiers distant par mount_smbfs.
* Justement, smbfs... J'ai été tout d'abord impressionné (monter un
filesystem smb sous UNIX, ça ne m'était jamais arrivé jusque là).
mount -t smbfs //foo@PORTABLE/bar /mnt
Là où ça se complique... J'ai un PC sous 2K dont le nom est ORYCTEROPUSAFER.
La feinte précédente ne marche plus :
smbfs: server name 'ORYCTEROPUSAFER' too long"
J'essaie des versions tronquées... Bof... Direct l'IP au lieu du nom :
smbfs: can't get server address: syserr = Operation timed out
OK, je m'y prends mal, il faut l'option -I. Néanmoins, la commande :
mount_smbfs -I ip //foo@PORTABLE/bar /mnt
ne semble fonctionner que si PORTABLE est bien le nom de la machine, je
n'arrive pas à l'omettre. Le remplacer par un faux nom conduit à :
mount_smbfs: unable to open connection: syserr = Connection reset by
peer
Comment dois-je faire donc pour ma machine au nom trop long et à l'IP connue
? Et dans le cas IP connue / nom inconnu ???
* Ma clé USB (1.1) : parfaitement reconnue (fait parfois quelques erreurs
lorsqu'elle est branchée au démarrage, personne n'est parfait), mais les
débits sont ridicules : 80k/s ! Voici le log :
umass0: USB Drive U-DISK, rev 1.10/1.00, addr 3
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <YIHUA U-DISK 1.3A> Removable Direct Access SCSI-2 device
da0: 1.000MB/s transfers
da0: 61MB (126644 512 byte sectors: 64H 32S/T 61C)
(da0:umass-sim0:0:0:0): READ(6)/WRITE(6) not supported, increasing
minimum_cmd_size to 10.
Ah, inutile d'incriminer la clé, elle fonctionne trés bien sous W...
* Ma carte son USB : M-Audio Audiophile USB : j'étais content, FreeBSD est
le premier système où elle fonctionne, et de manière plug'n'play (j'avoue
être impressionné). J'ai commencé à déchanter ce soir, après avoir constaté
que, lors d'une lecture MP3, basculer en mode texte puis revenir sur X
crashe absolument tout. Dans les logs... apparemment les logs ne sont pas
conservés d'un démarrage à l'autre, pourtant j'ai bien dit de logger tout
dans all.log (/etc/syslog.conf). Bref. Le problème n'apparaît pas en
utilisant la carte son intégrée à la carte mère. Encore l'USB ?
* Ma souris USB (et encore l'USB...) : fonctionnement impeccable, sauf que
de temps en temps, pouf! plus de souris. Elle reste alimentée mais est
inutilisable, ceci aussi bien sous X qu'en mode texte. Je n'ai guère creusé
ce problème (tests, logs) vu qu'il suffit de la débrancher et de la
rebrancher pour que tout rentre dans l'ordre.
* J'aurais aimé pouvoir lire une partition ReiserFS sans passer par une
autre machine... Concernant l'UFS2, les background check font (sauf erreur
de ma part) ramer la machine, et je ne suis pas convaincu efficacité par
rapport à un vrai filesystem journalisé. Je n'ai jamais rien perdu sur du
NTFS (je sors...), sauf en conditions exceptionnelles (overclock bourrin du
BUS). De ce fait, ma confiance en le non-journalisé (imaginez, des années
en FAT(32)) est vraiment limitée.
* Vitesse de transfert en IDE : eh bien ce n'est pas glorieux : 15MB/s entre
deux WD 80GB, en UDMA100. Je veux bien admettre que je lisais du NTFS,
soit, mais ça reste vraiment faiblard.
Plus je l'utilise, plus je pense que FreeBSD 5 ne devrait pas être une
RELEASE mais encore une beta. Quoi qu'il en soit, toute aide concernant ces
divers problèmes serait la bienvenue. Merci d'avance.
* Ma clé USB (1.1) : parfaitement reconnue (fait parfois quelques erreurs lorsqu'elle est branchée au démarrage, personne n'est parfait), mais les débits sont ridicules : 80k/s ! Voici le log :
umass0: USB Drive U-DISK, rev 1.10/1.00, addr 3 da0 at umass-sim0 bus 0 target 0 lun 0 da0: <YIHUA U-DISK 1.3A> Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 61MB (126644 512 byte sectors: 64H 32S/T 61C) (da0:umass-sim0:0:0:0): READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10.
Ah, inutile d'incriminer la clé, elle fonctionne trés bien sous W...
Le système de fichiers msdos est trés lent sous FreeBSD, tout comme ext2. Le seul système qui marche bien est UFS, c'est évidemment un énorme handicap de FreeBSD.
* Ma souris USB (et encore l'USB...) : fonctionnement impeccable, sauf que de temps en temps, pouf! plus de souris. Elle reste alimentée mais est inutilisable, ceci aussi bien sous X qu'en mode texte. Je n'ai guère creusé ce problème (tests, logs) vu qu'il suffit de la débrancher et de la rebrancher pour que tout rentre dans l'ordre.
Chez moi la souris USB fonctionne parfaitement. Ca peut dépendre du contrôleur uhci ou ohci?
* J'aurais aimé pouvoir lire une partition ReiserFS sans passer par une autre machine... Concernant l'UFS2, les background check font (sauf erreur de ma part) ramer la machine, et je ne suis pas convaincu efficacité par rapport à un vrai filesystem journalisé. Je n'ai jamais rien perdu sur du NTFS (je sors...), sauf en conditions exceptionnelles (overclock bourrin du BUS). De ce fait, ma confiance en le non-journalisé (imaginez, des années en FAT(32)) est vraiment limitée.
Je crois que tu as raison.
* Vitesse de transfert en IDE : eh bien ce n'est pas glorieux : 15MB/s entre deux WD 80GB, en UDMA100. Je veux bien admettre que je lisais du NTFS, soit, mais ça reste vraiment faiblard.
C'est la faute au NTFS. Pour le débit brut sur les disques IDE, FreeBSD est trés bon.
Plus je l'utilise, plus je pense que FreeBSD 5 ne devrait pas être une RELEASE mais encore une beta. Quoi qu'il en soit, toute aide concernant ces divers problèmes serait la bienvenue. Merci d'avance.
S.W.
-- Michel Talon
Stéphane Witzmann <bill.area51@free.fr> wrote:
* Ma clé USB (1.1) : parfaitement reconnue (fait parfois quelques erreurs
lorsqu'elle est branchée au démarrage, personne n'est parfait), mais les
débits sont ridicules : 80k/s ! Voici le log :
umass0: USB Drive U-DISK, rev 1.10/1.00, addr 3
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <YIHUA U-DISK 1.3A> Removable Direct Access SCSI-2 device
da0: 1.000MB/s transfers
da0: 61MB (126644 512 byte sectors: 64H 32S/T 61C)
(da0:umass-sim0:0:0:0): READ(6)/WRITE(6) not supported, increasing
minimum_cmd_size to 10.
Ah, inutile d'incriminer la clé, elle fonctionne trés bien sous W...
Le système de fichiers msdos est trés lent sous FreeBSD, tout comme ext2.
Le seul système qui marche bien est UFS, c'est évidemment un énorme handicap
de FreeBSD.
* Ma souris USB (et encore l'USB...) : fonctionnement impeccable, sauf que
de temps en temps, pouf! plus de souris. Elle reste alimentée mais est
inutilisable, ceci aussi bien sous X qu'en mode texte. Je n'ai guère creusé
ce problème (tests, logs) vu qu'il suffit de la débrancher et de la
rebrancher pour que tout rentre dans l'ordre.
Chez moi la souris USB fonctionne parfaitement. Ca peut dépendre du contrôleur
uhci ou ohci?
* J'aurais aimé pouvoir lire une partition ReiserFS sans passer par une
autre machine... Concernant l'UFS2, les background check font (sauf erreur
de ma part) ramer la machine, et je ne suis pas convaincu efficacité par
rapport à un vrai filesystem journalisé. Je n'ai jamais rien perdu sur du
NTFS (je sors...), sauf en conditions exceptionnelles (overclock bourrin du
BUS). De ce fait, ma confiance en le non-journalisé (imaginez, des années
en FAT(32)) est vraiment limitée.
Je crois que tu as raison.
* Vitesse de transfert en IDE : eh bien ce n'est pas glorieux : 15MB/s entre
deux WD 80GB, en UDMA100. Je veux bien admettre que je lisais du NTFS,
soit, mais ça reste vraiment faiblard.
C'est la faute au NTFS. Pour le débit brut sur les disques IDE, FreeBSD est
trés bon.
Plus je l'utilise, plus je pense que FreeBSD 5 ne devrait pas être une
RELEASE mais encore une beta. Quoi qu'il en soit, toute aide concernant ces
divers problèmes serait la bienvenue. Merci d'avance.
* Ma clé USB (1.1) : parfaitement reconnue (fait parfois quelques erreurs lorsqu'elle est branchée au démarrage, personne n'est parfait), mais les débits sont ridicules : 80k/s ! Voici le log :
umass0: USB Drive U-DISK, rev 1.10/1.00, addr 3 da0 at umass-sim0 bus 0 target 0 lun 0 da0: <YIHUA U-DISK 1.3A> Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 61MB (126644 512 byte sectors: 64H 32S/T 61C) (da0:umass-sim0:0:0:0): READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10.
Ah, inutile d'incriminer la clé, elle fonctionne trés bien sous W...
Le système de fichiers msdos est trés lent sous FreeBSD, tout comme ext2. Le seul système qui marche bien est UFS, c'est évidemment un énorme handicap de FreeBSD.
* Ma souris USB (et encore l'USB...) : fonctionnement impeccable, sauf que de temps en temps, pouf! plus de souris. Elle reste alimentée mais est inutilisable, ceci aussi bien sous X qu'en mode texte. Je n'ai guère creusé ce problème (tests, logs) vu qu'il suffit de la débrancher et de la rebrancher pour que tout rentre dans l'ordre.
Chez moi la souris USB fonctionne parfaitement. Ca peut dépendre du contrôleur uhci ou ohci?
* J'aurais aimé pouvoir lire une partition ReiserFS sans passer par une autre machine... Concernant l'UFS2, les background check font (sauf erreur de ma part) ramer la machine, et je ne suis pas convaincu efficacité par rapport à un vrai filesystem journalisé. Je n'ai jamais rien perdu sur du NTFS (je sors...), sauf en conditions exceptionnelles (overclock bourrin du BUS). De ce fait, ma confiance en le non-journalisé (imaginez, des années en FAT(32)) est vraiment limitée.
Je crois que tu as raison.
* Vitesse de transfert en IDE : eh bien ce n'est pas glorieux : 15MB/s entre deux WD 80GB, en UDMA100. Je veux bien admettre que je lisais du NTFS, soit, mais ça reste vraiment faiblard.
C'est la faute au NTFS. Pour le débit brut sur les disques IDE, FreeBSD est trés bon.
Plus je l'utilise, plus je pense que FreeBSD 5 ne devrait pas être une RELEASE mais encore une beta. Quoi qu'il en soit, toute aide concernant ces divers problèmes serait la bienvenue. Merci d'avance.
S.W.
-- Michel Talon
Marwan FeanoR/var Burelle
On Sun, 28 Dec 2003 04:11:58 +0100 Stéphane Witzmann wrote:
* J'aurais aimé pouvoir lire une partition ReiserFS sans passer par une autre machine... Concernant l'UFS2, les background check font (sauf erreur de ma part) ramer la machine, et je ne suis pas convaincu efficacité par rapport à un vrai filesystem journalisé. Je n'ai jamais rien perdu sur du NTFS (je sors...), sauf en conditions exceptionnelles (overclock bourrin du BUS). De ce fait, ma confiance en le non-journalisé (imaginez, des années en FAT(32)) est vraiment limitée.
Les gens de FreeBSD ont leur raisons apparement (il me semblais avoir vu passer un papier Usenix la dessus, mais je n'arrives pas à remettre la main dessus, par contre, il y a le papier de Thomas Pornin : http://www.freebsd-fr.org/doc/fr/books/systeme-fichier/index.html qui t'expliquera un peu la différence entre softupdates et journalisation et la réelle différence que ça fait ... )
Je rajouterais qu'il existe un fs journalisé *BSD qui fait partie des bouts non utilisés dans les sources de 4.4BSD lite par la plus part des BSD libres (il me semble qu'il y avait quelque chose chez NetBSD, mais je ne suis pas sûr) toujours est il que, les *BSD ont fait un choix (softupdates) qui ne semble pas moins intéressant que la journalisation (à part pour fsck ;)
* Vitesse de transfert en IDE : eh bien ce n'est pas glorieux : 15MB/s entre deux WD 80GB, en UDMA100. Je veux bien admettre que je lisais du NTFS, soit, mais ça reste vraiment faiblard.
Comme l'a dit Michel, NTFS ... et puis bon ... c'est de l'ide hein ...
Plus je l'utilise, plus je pense que FreeBSD 5 ne devrait pas être une RELEASE mais encore une beta. Quoi qu'il en soit, toute aide concernant ces divers problèmes serait la bienvenue. Merci d'avance.
C'est une release de test, as-tu lu http://www.freebsd.org/releases/5.1R/announce.html et http://www.freebsd.org/releases/5.1R/early-adopter.html ?
La branche 5 reste, pour l'instant la branche de developpement, même si, probablement pour tenter de faire un peu bouger la stabilisation de la branche, il y a eu 2 release dans cette branche (et une troisième qui arrive et qui d'ailleurs m'a bien plus satisfait que la 5.1, je vais peut être quitter -STABLE, moi ;)
On Sun, 28 Dec 2003 04:11:58 +0100
Stéphane Witzmann <bill.area51@free.fr> wrote:
* J'aurais aimé pouvoir lire une partition ReiserFS sans passer par une
autre machine... Concernant l'UFS2, les background check font (sauf
erreur de ma part) ramer la machine, et je ne suis pas convaincu
efficacité par rapport à un vrai filesystem journalisé. Je n'ai jamais
rien perdu sur du NTFS (je sors...), sauf en conditions exceptionnelles
(overclock bourrin du BUS). De ce fait, ma confiance en le
non-journalisé (imaginez, des années en FAT(32)) est vraiment limitée.
Les gens de FreeBSD ont leur raisons apparement (il me semblais avoir vu
passer un papier Usenix la dessus, mais je n'arrives pas à remettre la
main dessus, par contre, il y a le papier de Thomas Pornin :
http://www.freebsd-fr.org/doc/fr/books/systeme-fichier/index.html qui
t'expliquera un peu la différence entre softupdates et journalisation et
la réelle différence que ça fait ... )
Je rajouterais qu'il existe un fs journalisé *BSD qui fait partie des
bouts non utilisés dans les sources de 4.4BSD lite par la plus part des
BSD libres (il me semble qu'il y avait quelque chose chez NetBSD, mais je
ne suis pas sûr) toujours est il que, les *BSD ont fait un choix
(softupdates) qui ne semble pas moins intéressant que la journalisation (à
part pour fsck ;)
* Vitesse de transfert en IDE : eh bien ce n'est pas glorieux : 15MB/s
entre deux WD 80GB, en UDMA100. Je veux bien admettre que je lisais du
NTFS, soit, mais ça reste vraiment faiblard.
Comme l'a dit Michel, NTFS ... et puis bon ... c'est de l'ide hein ...
Plus je l'utilise, plus je pense que FreeBSD 5 ne devrait pas être une
RELEASE mais encore une beta. Quoi qu'il en soit, toute aide concernant
ces divers problèmes serait la bienvenue. Merci d'avance.
C'est une release de test, as-tu lu
http://www.freebsd.org/releases/5.1R/announce.html et
http://www.freebsd.org/releases/5.1R/early-adopter.html ?
La branche 5 reste, pour l'instant la branche de developpement, même si,
probablement pour tenter de faire un peu bouger la stabilisation de la
branche, il y a eu 2 release dans cette branche (et une troisième qui
arrive et qui d'ailleurs m'a bien plus satisfait que la 5.1, je vais peut
être quitter -STABLE, moi ;)
On Sun, 28 Dec 2003 04:11:58 +0100 Stéphane Witzmann wrote:
* J'aurais aimé pouvoir lire une partition ReiserFS sans passer par une autre machine... Concernant l'UFS2, les background check font (sauf erreur de ma part) ramer la machine, et je ne suis pas convaincu efficacité par rapport à un vrai filesystem journalisé. Je n'ai jamais rien perdu sur du NTFS (je sors...), sauf en conditions exceptionnelles (overclock bourrin du BUS). De ce fait, ma confiance en le non-journalisé (imaginez, des années en FAT(32)) est vraiment limitée.
Les gens de FreeBSD ont leur raisons apparement (il me semblais avoir vu passer un papier Usenix la dessus, mais je n'arrives pas à remettre la main dessus, par contre, il y a le papier de Thomas Pornin : http://www.freebsd-fr.org/doc/fr/books/systeme-fichier/index.html qui t'expliquera un peu la différence entre softupdates et journalisation et la réelle différence que ça fait ... )
Je rajouterais qu'il existe un fs journalisé *BSD qui fait partie des bouts non utilisés dans les sources de 4.4BSD lite par la plus part des BSD libres (il me semble qu'il y avait quelque chose chez NetBSD, mais je ne suis pas sûr) toujours est il que, les *BSD ont fait un choix (softupdates) qui ne semble pas moins intéressant que la journalisation (à part pour fsck ;)
* Vitesse de transfert en IDE : eh bien ce n'est pas glorieux : 15MB/s entre deux WD 80GB, en UDMA100. Je veux bien admettre que je lisais du NTFS, soit, mais ça reste vraiment faiblard.
Comme l'a dit Michel, NTFS ... et puis bon ... c'est de l'ide hein ...
Plus je l'utilise, plus je pense que FreeBSD 5 ne devrait pas être une RELEASE mais encore une beta. Quoi qu'il en soit, toute aide concernant ces divers problèmes serait la bienvenue. Merci d'avance.
C'est une release de test, as-tu lu http://www.freebsd.org/releases/5.1R/announce.html et http://www.freebsd.org/releases/5.1R/early-adopter.html ?
La branche 5 reste, pour l'instant la branche de developpement, même si, probablement pour tenter de faire un peu bouger la stabilisation de la branche, il y a eu 2 release dans cette branche (et une troisième qui arrive et qui d'ailleurs m'a bien plus satisfait que la 5.1, je vais peut être quitter -STABLE, moi ;)
Je rajouterais qu'il existe un fs journalisé *BSD qui fait partie des bouts non utilisés dans les sources de 4.4BSD lite par la plus part des BSD libres (il me semble qu'il y avait quelque chose chez NetBSD, mais je ne suis pas sûr) toujours est il que, les *BSD ont fait un choix (softupdates) qui ne semble pas moins intéressant que la journalisation (à part pour fsck ;)
lfs n'est pas un système journalisé, c'est un système à historique, ce qui est plus simple à mettre en oeuvre, mais consomme plus d'espace disque, et nécessite une assistance userland (lfs_cleanerd) pour ressembler à un système de fichiers utilisables.
Il y eu l'an dernier pas mal de travail sur lfsv2 dans NetBSD, qui effectivement est utilisable.
Je rajouterais qu'il existe un fs journalisé *BSD qui fait partie des
bouts non utilisés dans les sources de 4.4BSD lite par la plus part des
BSD libres (il me semble qu'il y avait quelque chose chez NetBSD, mais je
ne suis pas sûr) toujours est il que, les *BSD ont fait un choix
(softupdates) qui ne semble pas moins intéressant que la journalisation (à
part pour fsck ;)
lfs n'est pas un système journalisé, c'est un système à historique, ce
qui est plus simple à mettre en oeuvre, mais consomme plus d'espace
disque, et nécessite une assistance userland (lfs_cleanerd) pour
ressembler à un système de fichiers utilisables.
Il y eu l'an dernier pas mal de travail sur lfsv2 dans NetBSD, qui
effectivement est utilisable.
Je rajouterais qu'il existe un fs journalisé *BSD qui fait partie des bouts non utilisés dans les sources de 4.4BSD lite par la plus part des BSD libres (il me semble qu'il y avait quelque chose chez NetBSD, mais je ne suis pas sûr) toujours est il que, les *BSD ont fait un choix (softupdates) qui ne semble pas moins intéressant que la journalisation (à part pour fsck ;)
lfs n'est pas un système journalisé, c'est un système à historique, ce qui est plus simple à mettre en oeuvre, mais consomme plus d'espace disque, et nécessite une assistance userland (lfs_cleanerd) pour ressembler à un système de fichiers utilisables.
Il y eu l'an dernier pas mal de travail sur lfsv2 dans NetBSD, qui effectivement est utilisable.
Marwan FeanoR/var Burelle
On Sun, 28 Dec 2003 15:45:37 +0000 (UTC) Miod Vallat wrote:
lfs n'est pas un système journalisé, c'est un système à historique, ce qui est plus simple à mettre en oeuvre, mais consomme plus d'espace disque, et nécessite une assistance userland (lfs_cleanerd) pour ressembler à un système de fichiers utilisables.
Il y eu l'an dernier pas mal de travail sur lfsv2 dans NetBSD, qui effectivement est utilisable.
Effectivement ... c'est aussi la différence entre "journaling" et "journalized" ?
Ah, au fait, j'ai remis la main sur le papier Usenix : http://www.usenix.org/publications/library/proceedings/usenix2000/general/seltzer.html
On Sun, 28 Dec 2003 15:45:37 +0000 (UTC)
Miod Vallat <miod@online.fr> wrote:
lfs n'est pas un système journalisé, c'est un système à historique, ce
qui est plus simple à mettre en oeuvre, mais consomme plus d'espace
disque, et nécessite une assistance userland (lfs_cleanerd) pour
ressembler à un système de fichiers utilisables.
Il y eu l'an dernier pas mal de travail sur lfsv2 dans NetBSD, qui
effectivement est utilisable.
Effectivement ... c'est aussi la différence entre "journaling" et
"journalized" ?
Ah, au fait, j'ai remis la main sur le papier Usenix :
http://www.usenix.org/publications/library/proceedings/usenix2000/general/seltzer.html
On Sun, 28 Dec 2003 15:45:37 +0000 (UTC) Miod Vallat wrote:
lfs n'est pas un système journalisé, c'est un système à historique, ce qui est plus simple à mettre en oeuvre, mais consomme plus d'espace disque, et nécessite une assistance userland (lfs_cleanerd) pour ressembler à un système de fichiers utilisables.
Il y eu l'an dernier pas mal de travail sur lfsv2 dans NetBSD, qui effectivement est utilisable.
Effectivement ... c'est aussi la différence entre "journaling" et "journalized" ?
Ah, au fait, j'ai remis la main sur le papier Usenix : http://www.usenix.org/publications/library/proceedings/usenix2000/general/seltzer.html
* Ma clé USB (1.1) : parfaitement reconnue (fait parfois quelques erreurs lorsqu'elle est branchée au démarrage, personne n'est parfait), mais les débits sont ridicules : 80k/s ! Voici le log :
umass0: USB Drive U-DISK, rev 1.10/1.00, addr 3 da0 at umass-sim0 bus 0 target 0 lun 0 da0: <YIHUA U-DISK 1.3A> Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 61MB (126644 512 byte sectors: 64H 32S/T 61C) (da0:umass-sim0:0:0:0): READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10.
Ah, inutile d'incriminer la clé, elle fonctionne trés bien sous W...
Le système de fichiers msdos est trés lent sous FreeBSD, tout comme ext2. Le seul système qui marche bien est UFS, c'est évidemment un énorme handicap de FreeBSD.
Nouveau test, cette fois-ci en UFS2. Lecture : 813 k/s (en moyenne) Ecriture : 303 k/s (idem)
C'est mieux !
* Vitesse de transfert en IDE : eh bien ce n'est pas glorieux : 15MB/s entre deux WD 80GB, en UDMA100. Je veux bien admettre que je lisais du NTFS, soit, mais ça reste vraiment faiblard.
C'est la faute au NTFS. Pour le débit brut sur les disques IDE, FreeBSD est trés bon.
Je viens de faire un test UFS2->UFS2 : 28 MB/s. C'est mieux.
Question : y aurait-il un moyen de mieux implémenter les autres systèmes de fichiers ? Ou alors ces performances déplorables sont inhérentes à la structure du noyau BSD ? Pour le NTFS, rien de vraiment grave, par contre le msdosfs, c'est la catastrophe.
talon@lpthe.jussieu.fr wrote:
Stéphane Witzmann <bill.area51@free.fr> wrote:
* Ma clé USB (1.1) : parfaitement reconnue (fait parfois quelques erreurs
lorsqu'elle est branchée au démarrage, personne n'est parfait), mais les
débits sont ridicules : 80k/s ! Voici le log :
umass0: USB Drive U-DISK, rev 1.10/1.00, addr 3
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <YIHUA U-DISK 1.3A> Removable Direct Access SCSI-2 device
da0: 1.000MB/s transfers
da0: 61MB (126644 512 byte sectors: 64H 32S/T 61C)
(da0:umass-sim0:0:0:0): READ(6)/WRITE(6) not supported, increasing
minimum_cmd_size to 10.
Ah, inutile d'incriminer la clé, elle fonctionne trés bien sous W...
Le système de fichiers msdos est trés lent sous FreeBSD, tout comme ext2.
Le seul système qui marche bien est UFS, c'est évidemment un énorme
handicap de FreeBSD.
Nouveau test, cette fois-ci en UFS2.
Lecture : 813 k/s (en moyenne)
Ecriture : 303 k/s (idem)
C'est mieux !
* Vitesse de transfert en IDE : eh bien ce n'est pas glorieux : 15MB/s
entre deux WD 80GB, en UDMA100. Je veux bien admettre que je lisais du
NTFS, soit, mais ça reste vraiment faiblard.
C'est la faute au NTFS. Pour le débit brut sur les disques IDE, FreeBSD
est trés bon.
Je viens de faire un test UFS2->UFS2 : 28 MB/s. C'est mieux.
Question : y aurait-il un moyen de mieux implémenter les autres systèmes de
fichiers ? Ou alors ces performances déplorables sont inhérentes à la
structure du noyau BSD ? Pour le NTFS, rien de vraiment grave, par contre
le msdosfs, c'est la catastrophe.
* Ma clé USB (1.1) : parfaitement reconnue (fait parfois quelques erreurs lorsqu'elle est branchée au démarrage, personne n'est parfait), mais les débits sont ridicules : 80k/s ! Voici le log :
umass0: USB Drive U-DISK, rev 1.10/1.00, addr 3 da0 at umass-sim0 bus 0 target 0 lun 0 da0: <YIHUA U-DISK 1.3A> Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 61MB (126644 512 byte sectors: 64H 32S/T 61C) (da0:umass-sim0:0:0:0): READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10.
Ah, inutile d'incriminer la clé, elle fonctionne trés bien sous W...
Le système de fichiers msdos est trés lent sous FreeBSD, tout comme ext2. Le seul système qui marche bien est UFS, c'est évidemment un énorme handicap de FreeBSD.
Nouveau test, cette fois-ci en UFS2. Lecture : 813 k/s (en moyenne) Ecriture : 303 k/s (idem)
C'est mieux !
* Vitesse de transfert en IDE : eh bien ce n'est pas glorieux : 15MB/s entre deux WD 80GB, en UDMA100. Je veux bien admettre que je lisais du NTFS, soit, mais ça reste vraiment faiblard.
C'est la faute au NTFS. Pour le débit brut sur les disques IDE, FreeBSD est trés bon.
Je viens de faire un test UFS2->UFS2 : 28 MB/s. C'est mieux.
Question : y aurait-il un moyen de mieux implémenter les autres systèmes de fichiers ? Ou alors ces performances déplorables sont inhérentes à la structure du noyau BSD ? Pour le NTFS, rien de vraiment grave, par contre le msdosfs, c'est la catastrophe.
Marwan FeanoR/var Burelle
On Sun, 28 Dec 2003 17:46:11 +0100 Stéphane Witzmann wrote:
Question : y aurait-il un moyen de mieux implémenter les autres systèmes de fichiers ? Ou alors ces performances déplorables sont inhérentes à la structure du noyau BSD ? Pour le NTFS, rien de vraiment grave, par contre le msdosfs, c'est la catastrophe.
Il me semble (mais vu que ça à du être fait) qu'il était question d'intégrer le support fat de darwin (qui serait meilleur) pour la 5.2, mais je suis pas sûr du tout ...
On Sun, 28 Dec 2003 17:46:11 +0100
Stéphane Witzmann <bill.area51@free.fr> wrote:
Question : y aurait-il un moyen de mieux implémenter les autres
systèmes de fichiers ? Ou alors ces performances déplorables sont
inhérentes à la structure du noyau BSD ? Pour le NTFS, rien de vraiment
grave, par contre le msdosfs, c'est la catastrophe.
Il me semble (mais vu que ça à du être fait) qu'il était question
d'intégrer le support fat de darwin (qui serait meilleur) pour la 5.2,
mais je suis pas sûr du tout ...
On Sun, 28 Dec 2003 17:46:11 +0100 Stéphane Witzmann wrote:
Question : y aurait-il un moyen de mieux implémenter les autres systèmes de fichiers ? Ou alors ces performances déplorables sont inhérentes à la structure du noyau BSD ? Pour le NTFS, rien de vraiment grave, par contre le msdosfs, c'est la catastrophe.
Il me semble (mais vu que ça à du être fait) qu'il était question d'intégrer le support fat de darwin (qui serait meilleur) pour la 5.2, mais je suis pas sûr du tout ...
On Sun, 28 Dec 2003 04:11:58 +0100 Stéphane Witzmann wrote:
* J'aurais aimé pouvoir lire une partition ReiserFS sans passer par une autre machine... Concernant l'UFS2, les background check font (sauf erreur de ma part) ramer la machine, et je ne suis pas convaincu efficacité par rapport à un vrai filesystem journalisé. Je n'ai jamais rien perdu sur du NTFS (je sors...), sauf en conditions exceptionnelles (overclock bourrin du BUS). De ce fait, ma confiance en le non-journalisé (imaginez, des années en FAT(32)) est vraiment limitée.
Les gens de FreeBSD ont leur raisons apparement (il me semblais avoir vu passer un papier Usenix la dessus, mais je n'arrives pas à remettre la main dessus, par contre, il y a le papier de Thomas Pornin : http://www.freebsd-fr.org/doc/fr/books/systeme-fichier/index.html qui t'expliquera un peu la différence entre softupdates et journalisation et la réelle différence que ça fait ... )
Effectivement. Mais... pourquoi par défaut la racine n'utilise-t-elle pas les softupdates (a chaque crash, le système nécessite une intervention humaine pour checker la racine) ? Comment faire pour la monter automatiquement en softupdates (si possible) ?
Marwan FeanoR/var Burelle wrote:
On Sun, 28 Dec 2003 04:11:58 +0100
Stéphane Witzmann <bill.area51@free.fr> wrote:
* J'aurais aimé pouvoir lire une partition ReiserFS sans passer par une
autre machine... Concernant l'UFS2, les background check font (sauf
erreur de ma part) ramer la machine, et je ne suis pas convaincu
efficacité par rapport à un vrai filesystem journalisé. Je n'ai jamais
rien perdu sur du NTFS (je sors...), sauf en conditions exceptionnelles
(overclock bourrin du BUS). De ce fait, ma confiance en le
non-journalisé (imaginez, des années en FAT(32)) est vraiment limitée.
Les gens de FreeBSD ont leur raisons apparement (il me semblais avoir vu
passer un papier Usenix la dessus, mais je n'arrives pas à remettre la
main dessus, par contre, il y a le papier de Thomas Pornin :
http://www.freebsd-fr.org/doc/fr/books/systeme-fichier/index.html qui
t'expliquera un peu la différence entre softupdates et journalisation et
la réelle différence que ça fait ... )
Effectivement. Mais... pourquoi par défaut la racine n'utilise-t-elle pas
les softupdates (a chaque crash, le système nécessite une intervention
humaine pour checker la racine) ? Comment faire pour la monter
automatiquement en softupdates (si possible) ?
On Sun, 28 Dec 2003 04:11:58 +0100 Stéphane Witzmann wrote:
* J'aurais aimé pouvoir lire une partition ReiserFS sans passer par une autre machine... Concernant l'UFS2, les background check font (sauf erreur de ma part) ramer la machine, et je ne suis pas convaincu efficacité par rapport à un vrai filesystem journalisé. Je n'ai jamais rien perdu sur du NTFS (je sors...), sauf en conditions exceptionnelles (overclock bourrin du BUS). De ce fait, ma confiance en le non-journalisé (imaginez, des années en FAT(32)) est vraiment limitée.
Les gens de FreeBSD ont leur raisons apparement (il me semblais avoir vu passer un papier Usenix la dessus, mais je n'arrives pas à remettre la main dessus, par contre, il y a le papier de Thomas Pornin : http://www.freebsd-fr.org/doc/fr/books/systeme-fichier/index.html qui t'expliquera un peu la différence entre softupdates et journalisation et la réelle différence que ça fait ... )
Effectivement. Mais... pourquoi par défaut la racine n'utilise-t-elle pas les softupdates (a chaque crash, le système nécessite une intervention humaine pour checker la racine) ? Comment faire pour la monter automatiquement en softupdates (si possible) ?
Stéphane Witzmann
Rebonjour
Pendant que j'y suis, une autre question. Il semblerait que, sous FreeBSD, tout fichier créé hérite automatiquement du GID du répertoire parent (qu'il soit SETGID ou pas). Linux, en comparaison, se comporte "normalement". Ce choix est-il historique, et dans quel but a-t-il été fait ? Peut-on désactiver cette option ?
S.W.
Rebonjour
Pendant que j'y suis, une autre question. Il semblerait que, sous FreeBSD,
tout fichier créé hérite automatiquement du GID du répertoire parent (qu'il
soit SETGID ou pas). Linux, en comparaison, se comporte "normalement". Ce
choix est-il historique, et dans quel but a-t-il été fait ? Peut-on
désactiver cette option ?
Pendant que j'y suis, une autre question. Il semblerait que, sous FreeBSD, tout fichier créé hérite automatiquement du GID du répertoire parent (qu'il soit SETGID ou pas). Linux, en comparaison, se comporte "normalement". Ce choix est-il historique, et dans quel but a-t-il été fait ? Peut-on désactiver cette option ?
S.W.
talon
Stéphane Witzmann wrote:
C'est la faute au NTFS. Pour le débit brut sur les disques IDE, FreeBSD est trés bon.
Je viens de faire un test UFS2->UFS2 : 28 MB/s. C'est mieux.
Question : y aurait-il un moyen de mieux implémenter les autres systèmes de fichiers ? Ou alors ces performances déplorables sont inhérentes à la structure du noyau BSD ? Pour le NTFS, rien de vraiment grave, par contre le msdosfs, c'est la catastrophe.
En effet. C'est profondément du à la structure des BSD, le système de fichiers est beaucoup trop imbriqué avec le reste de l'OS. Du coup il est trés difficile de porter des systèmes de fichiers étrangers, tels que les fichiers journalisés de Linux, il est trés difficile de préserver les performances avec un autre système de fichiers, etc. Du coup c'est un des buts de DragonFlyBSD de casser cette intégration du système de fichiers à l'OS, au point même de fournir une interface hors du noyau aux systèmes de fichiers.
-- Michel Talon
Stéphane Witzmann <bill.area51@free.fr> wrote:
C'est la faute au NTFS. Pour le débit brut sur les disques IDE, FreeBSD
est trés bon.
Je viens de faire un test UFS2->UFS2 : 28 MB/s. C'est mieux.
Question : y aurait-il un moyen de mieux implémenter les autres systèmes de
fichiers ? Ou alors ces performances déplorables sont inhérentes à la
structure du noyau BSD ? Pour le NTFS, rien de vraiment grave, par contre
le msdosfs, c'est la catastrophe.
En effet. C'est profondément du à la structure des BSD, le système de fichiers
est beaucoup trop imbriqué avec le reste de l'OS. Du coup il est trés
difficile de porter des systèmes de fichiers étrangers, tels que les fichiers
journalisés de Linux, il est trés difficile de préserver les performances avec
un autre système de fichiers, etc. Du coup c'est un des buts de DragonFlyBSD
de casser cette intégration du système de fichiers à l'OS, au point même de
fournir une interface hors du noyau aux systèmes de fichiers.
C'est la faute au NTFS. Pour le débit brut sur les disques IDE, FreeBSD est trés bon.
Je viens de faire un test UFS2->UFS2 : 28 MB/s. C'est mieux.
Question : y aurait-il un moyen de mieux implémenter les autres systèmes de fichiers ? Ou alors ces performances déplorables sont inhérentes à la structure du noyau BSD ? Pour le NTFS, rien de vraiment grave, par contre le msdosfs, c'est la catastrophe.
En effet. C'est profondément du à la structure des BSD, le système de fichiers est beaucoup trop imbriqué avec le reste de l'OS. Du coup il est trés difficile de porter des systèmes de fichiers étrangers, tels que les fichiers journalisés de Linux, il est trés difficile de préserver les performances avec un autre système de fichiers, etc. Du coup c'est un des buts de DragonFlyBSD de casser cette intégration du système de fichiers à l'OS, au point même de fournir une interface hors du noyau aux systèmes de fichiers.
-- Michel Talon
talon
Marwan FeanoR/var Burelle wrote:
On Sun, 28 Dec 2003 04:11:58 +0100 Stéphane Witzmann wrote:
* J'aurais aimé pouvoir lire une partition ReiserFS sans passer par une autre machine... Concernant l'UFS2, les background check font (sauf erreur de ma part) ramer la machine, et je ne suis pas convaincu efficacité par rapport à un vrai filesystem journalisé. Je n'ai jamais rien perdu sur du NTFS (je sors...), sauf en conditions exceptionnelles (overclock bourrin du BUS). De ce fait, ma confiance en le non-journalisé (imaginez, des années en FAT(32)) est vraiment limitée.
Les gens de FreeBSD ont leur raisons apparement (il me semblais avoir vu passer un papier Usenix la dessus, mais je n'arrives pas à remettre la main dessus, par contre, il y a le papier de Thomas Pornin : http://www.freebsd-fr.org/doc/fr/books/systeme-fichier/index.html qui t'expliquera un peu la différence entre softupdates et journalisation et la réelle différence que ça fait ... )
A mon avis le choix de softupdates a été une erreur et c'est maintenant qu'elle se paye. Même si softupdates offre d'aussi bonnes performances que les systèmes journalisés (ou un peu meilleures) et les mêmes garanties en cas de crash, il n'en reste pas moins que dans quelques rares cas on est amené à faire un fsck manuel complet. C'est déjà arrivé à un certain nombre de gens. Or, avec la taille des disques qui augmente à toute vitesse, il devient purement et simplement impossible de faire un fsck dans un laps de temps raisonnable. Ce qui veut dire que les systèmes nécessitant un fsck sont condamnés dans un futur proche. En outre softupdates est d'une complexité considérable, et n'est probablement compris que par son auteur, ce qui ne peut que laisser planer des doutes sur la suite. Il me semble clair, surtout vu que Linux est devenu le système libre largement dominant, que les BSD doivent avoir la compatibilité avec au moins un important système de fichiers journalisé de Linux (XFS, JFS, ou Reiserfs) ne serait-ce que pour faciliter les échanges et ne pas tomber dans l'irrelevance. Si c'était possible NTFS serait aussi indispensable, malheureusement il ne faut pas rêver.
-- Michel Talon
Marwan FeanoR/var Burelle <burelle@lri.fr> wrote:
On Sun, 28 Dec 2003 04:11:58 +0100
Stéphane Witzmann <bill.area51@free.fr> wrote:
* J'aurais aimé pouvoir lire une partition ReiserFS sans passer par une
autre machine... Concernant l'UFS2, les background check font (sauf
erreur de ma part) ramer la machine, et je ne suis pas convaincu
efficacité par rapport à un vrai filesystem journalisé. Je n'ai jamais
rien perdu sur du NTFS (je sors...), sauf en conditions exceptionnelles
(overclock bourrin du BUS). De ce fait, ma confiance en le
non-journalisé (imaginez, des années en FAT(32)) est vraiment limitée.
Les gens de FreeBSD ont leur raisons apparement (il me semblais avoir vu
passer un papier Usenix la dessus, mais je n'arrives pas à remettre la
main dessus, par contre, il y a le papier de Thomas Pornin :
http://www.freebsd-fr.org/doc/fr/books/systeme-fichier/index.html qui
t'expliquera un peu la différence entre softupdates et journalisation et
la réelle différence que ça fait ... )
A mon avis le choix de softupdates a été une erreur et c'est maintenant
qu'elle se paye. Même si softupdates offre d'aussi bonnes performances
que les systèmes journalisés (ou un peu meilleures) et les mêmes garanties en
cas de crash, il n'en reste pas moins que dans quelques rares cas on est amené
à faire un fsck manuel complet. C'est déjà arrivé à un certain nombre de gens.
Or, avec la taille des disques qui augmente à toute vitesse, il devient
purement et simplement impossible de faire un fsck dans un laps de temps
raisonnable. Ce qui veut dire que les systèmes nécessitant un fsck sont
condamnés dans un futur proche. En outre softupdates est d'une complexité
considérable, et n'est probablement compris que par son auteur, ce qui ne peut
que laisser planer des doutes sur la suite. Il me semble clair, surtout vu
que Linux est devenu le système libre largement dominant, que les BSD doivent
avoir la compatibilité avec au moins un important système de fichiers
journalisé de Linux (XFS, JFS, ou Reiserfs) ne serait-ce que pour faciliter
les échanges et ne pas tomber dans l'irrelevance. Si c'était possible NTFS
serait aussi indispensable, malheureusement il ne faut pas rêver.
On Sun, 28 Dec 2003 04:11:58 +0100 Stéphane Witzmann wrote:
* J'aurais aimé pouvoir lire une partition ReiserFS sans passer par une autre machine... Concernant l'UFS2, les background check font (sauf erreur de ma part) ramer la machine, et je ne suis pas convaincu efficacité par rapport à un vrai filesystem journalisé. Je n'ai jamais rien perdu sur du NTFS (je sors...), sauf en conditions exceptionnelles (overclock bourrin du BUS). De ce fait, ma confiance en le non-journalisé (imaginez, des années en FAT(32)) est vraiment limitée.
Les gens de FreeBSD ont leur raisons apparement (il me semblais avoir vu passer un papier Usenix la dessus, mais je n'arrives pas à remettre la main dessus, par contre, il y a le papier de Thomas Pornin : http://www.freebsd-fr.org/doc/fr/books/systeme-fichier/index.html qui t'expliquera un peu la différence entre softupdates et journalisation et la réelle différence que ça fait ... )
A mon avis le choix de softupdates a été une erreur et c'est maintenant qu'elle se paye. Même si softupdates offre d'aussi bonnes performances que les systèmes journalisés (ou un peu meilleures) et les mêmes garanties en cas de crash, il n'en reste pas moins que dans quelques rares cas on est amené à faire un fsck manuel complet. C'est déjà arrivé à un certain nombre de gens. Or, avec la taille des disques qui augmente à toute vitesse, il devient purement et simplement impossible de faire un fsck dans un laps de temps raisonnable. Ce qui veut dire que les systèmes nécessitant un fsck sont condamnés dans un futur proche. En outre softupdates est d'une complexité considérable, et n'est probablement compris que par son auteur, ce qui ne peut que laisser planer des doutes sur la suite. Il me semble clair, surtout vu que Linux est devenu le système libre largement dominant, que les BSD doivent avoir la compatibilité avec au moins un important système de fichiers journalisé de Linux (XFS, JFS, ou Reiserfs) ne serait-ce que pour faciliter les échanges et ne pas tomber dans l'irrelevance. Si c'était possible NTFS serait aussi indispensable, malheureusement il ne faut pas rêver.
