benoar a écrit 4238 commentaires

À priori, si tu gardes la solution tunnel SSH, je ne vois pas de moyen "facile" de faire ça. Je te dirais de passer par un VPN à ce moment là.
Après, je ne vois pas trop l'intérêt d'accéder à tes partages locaux Samba, mais bon ...

Cet article se fait proprement démonter dans les commentaires : c'est une grosse connerie, ils ne comptent pas si la RAM est utilisée comme cache ou non.

C'est une histoire de compromis. Bien sûr, rien n'est 100% sécurisé. Mais si tu fous une option dans l'interface web du firmware bien visible "niquer france telecom", ça ne passera pas.

Manquerait plus qu'on tienne le constructeur pour responsable de l'usage qui est fait par l'utilisateur, tiens!

Je dirais que l'analogie est un peu foireuse. Même si effectivement, la loi française sur les télécommunications rend le constructeur responsable de "bloquer" l'utilisation de ses produits hors des normes.

Une des principales raisons que je vois, c'est que ça peut déranger les militaires et les services d'urgence (sûrement que les premiers ont un bon pouvoir de pression). Alors qu'un mec qui tune sa voiture, il ne dérange "personne" (au sens de ma phrase précédente, hein).

Je sais pas pour toi, mais moi dans mon monde des informaticiens, on connaît très bien ce problème mais on arrive à se comprendre quand même.

(bon, pour le début de ton commentaire, je n'ai pas très bien compris si tu abondes dans mon sens ou non)

Le constructeur n'ont pas "à faire avec". La taille des secteurs est prévu d'être fournis. Ensuite, les auteurs de FS doivent prendre en compte cette information. La gestion est très proche d'une gestion de cluster, la seul différence est la possibilité d'une écriture partielle sur un bloc vierge.

C'est bien d'avoir les choses en place en théorie. Le truc c'est qu'en pratique on a encore du Windows XP partout. Et qu'il faut bien faire avec (= blocs logiques de 512o).

Bon, à priori, si c'est pour un Vista/Seven, ça devrait marcher. C'est ça ? C'était il n'y a pas très longtemps ?
Mais de toutes façons, "secteurs exposés du périphérique bloc", ça ne veut pas dire grand chose. Je viens de relire la norme ATA, et depuis la version 7 on dispose de commandes pour savoir quelle est la taille de bloc logique / physique, ainsi que l'alignement.

Peut-être que le firmware n'est pas encore prêt, et qu'ils n'ont pas encore bien testé les disques comme ça. Il faudra attendre un peu ...

Des secteurs logiques de 4kio ? Ou physiques, mais présentés en 512o ? Ou alors c'est les secteurs du FS dont tu nous parles ? (vu l'appellation, je pense que c'est ça)

D'après ce que j'ai compris, le jumper sur les WD sert uniquement à mettre l'alignement à -1 bloc en cas d'OS ne pouvant pas être aligné (de façon à ce que le 63 bloc soit aligné).

Pourtant, je peux parfaitement ne pas utiliser la Livebox et mettre n'importe quel autre modem à la place.. C'est à se demander ce qui leur est passé par la tête en écrivant ça.

Et ton autre modem, tu peux le flasher ? Non, il doit aussi respecter la législation en vigueur ...

Regarde un peu ce qui s'est passé pour le N770, puis pour les N8x0, et tu comprendras peut-être un peu mieux.

La fragmentation n'est pas "géré", il est fait comme si elle n'existait pas avec un pseudo système journalisé, qui forcément dégrade les performances pour faire les copies quand il n'y a plus de place dispo.

Je parle de la fragmentation sous la forme du wear-leveling : au contraire des disques classiques, il faut essayer de répartir les écritures sur le plus de zones possibles (enfin, tout en rassemblant les données le plus possible dans des blocs entiers).

Un "TRIM", c'est juste un "erase" pour rendre le secteur vierge.

Oui, et ? Sans TRIM, tu copies l'équivalent de la capacité de ton disque dessus et tu n'as plus aucun secteur libre ...

La taille des zones peut être lu sur les SSD.

C'est arrivé avec le 2.6.31 quand même ... Mais surtout, je n'ai vu absolument _aucun_ constructeur communiquer dessus. C'est un secret industriel qui n'est que rarement dévoilé. Et j'ai vérifié sur deux SSD chez moi (un "maison" avec des cartes CF, et un Photofast) et aucun n'indique sa taille de "bloc" (d'ailleurs, normalement un SSD n'a pas vraiment de zone (enfin, c'est flou, comme tout ce qui tourne autour des SSDs) contrairement aux SD/CF, car il fait du wear-leveling sur tout le disque ; on pourrait par contr ese demander quelle est sa taille de page et la taille des erase block).

Cela serait bien plus propre gérer au niveau FS. C'est "juste" une couche supplémentaire.

Oui enfin bon, là, cette possibilité, ça fait "longtemps" que les constructeurs l'ont oublié. Maintenant il faut faire avec ...

Bon, en fait ce n'est pas exactement un problème de fragmentation dont je parle, mais de l'histoire d'arriver à faire du wear-leveling correct, surtout quand le disque devient plein (donc encore plus problématique quand le SSD ne gère pas le TRIM). Les performances et la longévité du SSD vont grandement diminuer quand le SSD ne trouve pas facilement de place "libre" pour écrire tes données. En plus, s'il faut qu'il libère un bloc avant de pouvoir écrire (dans le cas où peu de blocs sont disponibles), tu vas avoir droit à un cycle de read/modify/write de la taille d'un erase bloc (plusieurs dizaines de ko, voire plusieurs mégas pour les SSD dans le futur, cf http://www.hardware.fr/news/imprimer/10713/ ), ce qui va prendre du temps.

Mais effectivement, ce n'est pas une histoire de temps d'accès dû à une contrainte physique ; c'est la "logique" derrière qui peut ralentir.

Tu n'as pas du bien comprendre : les SSD utilisent bien ce même "hack" (si tu veux l'appeler ainsi). Ils ont des blocs physiques de 4ko ou plus, mais exposent des blocs logiques de 512o. Comme tout périphérique de type bloc depuis des dizaines d'années. Parce que sans ça, ils ne fonctionneraient pas avec un Windows inférieur à Vista.

D'où le problème que tu cites avec l'alignement, qui est exactement le même sur les WD. C'est dû au décalage taille de bloc physique / logique qu'on trouve dans ces deux types de disque.

Le truc c'est que si tu fais des disques avec des blocs logiques de 4ko, tu peux dire bye-bye à tout Windows inférieur à Vista. Ce qui aurait fâché trop de gens ...

Il a déjà été montré plusieurs choses (dont je n'ai plus les références malheureusement) :
- adapter le kernel à une taille de bloc supérieure à une taille de page (4ko) serait un travail énorme
- le choix de 4ko est un compromis par rapport à l'utilisation qui est faite des petits fichiers

Bref, ce n'est pas si facile à changer, et surtout, ça a été réfléchi avant, quand même.

Les expressions régulière tel que présentées plus haut ne posent pas de problèmes avec les " n'importent où.

Et si, dans le cas où on a un guillemet échappé dans la chaîne ... OK, tu vas me dire, "ça arrivera jamais, aucune ville n'a de guillemet dans son nom", mais "on sait jamais" ... (je ferais bien plus attention aux erreurs de traitement qui pourraient par exemple intégrer un guillemet inséré à cause d'un bug de double échappement ou un truc du genre)

Ma "logique" c'était que tant qu'on a une lib qui suit la "norme" sans se prendre la tête avec les regexp, tout en ayant un langage qui permet d'aussi facilement l'utiliser, autant en profiter.

Enfin, mes excuses pour la pique sur les "vrais langages", c'est vrai que j'ai vu des morceaux de sed et awk assez impressionnant sur ce forum.

Moi je parle de problème de consistance des données en cas de "panne". Actuellement, une écriture de 512 octets est garantie pour être atomique (i.e. quand tu envoies l'écriture au disque et qu'il valide la commande, tu peux être sûr que c'est bien inscrit sur le disque, et pas en cache), mais pour 4ko (physique, et toujours 512o logique) je ne suis pas sûr, vu qu'il faut faire un read de 4ko, modifier les 512o, et écrire 4ko. S'il y a une coupure en plein milieu, je ne sais pas si le disque a le temps ou non d'écrire tout et de garantir l'atomicité.

La fragmentation est gérée en interne par le disque, alors l'OS n'y peut pas grand chose (et rien n'est prévu pour l'instant pour y donner "accès", au moins en lecture, dans les specs ATA). Par contre, la gestion du TRIM va grandement aider le contrôleur du SSD à "faire le ménage" dans ses tables et à éviter de trop fragmenter.

Ha effectivement, je viens de vérifier, et mes ext3 ont effectivement des blocs de 4ko. Attention, on parle bien ici des blocs du FS, pas du disque.

Mais donc cela devrait faciliter le problème de l'atomicité dont je parlais, et dont j'avais surtout entendu parler avec les SSD (qui ont des erase block encore plus gros). Je ne sais tout de même pas vraiment si ces 4ko sont utilisés comme "unité atomique" lors de l'écriture ; ils le sont en tous cas, et c'est leur premier rôle, pour l'adressage des blocs sur le FS.

Oui, effectivement. J'en ai une sur un portable acheté d'occasion, et donc comme j'avais "moins le choix", je fais avec, en utilisant nouveau.

Le CSV a beau être un format un peu bâtard, il existe certaines "normes" qui sont implémentées par les librairies adéquates. En particulier, enlever les guillemets doubles à l'arrache, pourquoi pas, mais on sait jamais, si une donnée est formatée un peu bizarrement ...

Bref, le code, en utilisant csv, en python :

import csv
for line in csv.reader(file("villes.csv")):
  print line[0] + line[1] + line[2]

Encore plus lisible que les solutions précédentes.
Et le mieux, c'est que comme tu es dans un vrai langage, tu pourras même utiliser les bindings SQL pour intégrer ça dans ta base ! Genre, après avoir récupéré un curseur "c", mettre dans la boucle :

c.execute("INSERT INTO matable (pays, ville, num) VALUES ?, ?, ?", line)

Voilà, je trouve ça encore plus efficace que les solutions précédentes.

linux utilise par exemple déjà cette valeur pour stocker les données dans des blocs logiques

Tu aurais une référence pour ça ? Je ne suis pas sur que ce soit vrai ... Linux a déjà la possibilité de s'adapter à des blocs physiques de taille autre que 512, mais là je ne vois pas ce dont tu parles.

Ensuite, j'espère que les FS qui font attention à l'atomicité des écritures sur disque vont être adaptés pour les disques 512o logiques/4ko physiques qui arrivent, car les cycles de read/modify/write changent un peu la sémantique du truc.

Les blocages : principalement les blobs et la gestion de projet vue par Nokia.

Les blobs, c'est connu, on sait que c'est ce qui tue le libre sur le long terme, mais ça se fait toujours. Le N900 aura le même problème (obligé de rester avec des vieilles versions des softs, etc).

Pour la gestion du projet, Maemo est très tenu par Nokia et très peu de décisions viennent de la communauté. Nokia est même très critiqué pour sa gestion de l'aspect communautaire dans Maemo. De plus, c'est une distro un peu spéciale, qui n'est pas si facile à gérer de la part d'une communauté qui n'est pas forcément spécialisée dedans.

On a même vu un fork de Maemo pour ses problèmes de blobs : Mer. Qui est fait par .... Nokia Brésil !