Journal Le monde informatique de nouveau révolutionné

Posté par  .
Étiquettes : aucune
20
15
fév.
2010
Cher lecteur,

tu n'es pas sans savoir que le monde informatique s'apprète à connaitre une nouvelle évolution (révolution ?).

Non, il ne s'agit pas d'un nouveau CPU (doté d'un enième core ou d'une fréquence d'horloge réhaussée).

Non, il ne s'agit pas d'une nouvelle version de mac os x, ni de windows, ni encore celle d'un prétendu kernel 3.0.

Non, il ne s'agit pas de l'ipad (ben oui c'est ballot il est déjà sorti).

Non, il ne s'agit pas d'un nouveau telephone (pda ?).

Non, il ne s'agit pas d'un nouveau film de chuck norris.

Le monde informatique est sur le point de faire la peau à une limitation (et maintenant un vestige) historique, celle de la taille des blocs physiques des disques durs !

Et oui, n'oublions pas que cette taille est toujours fixée à 512 octets !

Et par ailleurs, quoi qu'on en dise, les systèmes d'entrées-sorties, et en particulier les disques durs, constituent toujours le goulet (ou goulot je sais jamais) d'étranglement majeur de nos environnements.

L'idée est donc de passer les blocs physiques à 4Ko ; cette valeur ne semble pas être innocente, en effet linux utilise par exemple déjà cette valeur pour stocker les données dans des blocs logiques, ainsi on pourrais se passer d'une étape de mapping pour améliorer les performances.

Cette valeur correspond aussi à la taille des pages mémoire, ainsi le processus de pagination s'en trouverait favorablement impacté.

Passer à des blocs de 4kO, permettrait aussi de perdre moins de place par rapport à la capacité de stockage nominale, ben oui moins de méta données toussa...

http://www.silicon.fr/fr/news/2009/12/16/western_digital_aug(...)

Enfin, l'article suivant a attiré toute mon attention sur de probables problèmes de performances si l'on ne fait pas attention lors du partitionnement :

http://www.osnews.com/story/22872/Linux_Not_Fully_Prepared_f(...)

  • # j'ai que c'était la fin du BIOS

    Posté par  . Évalué à 10.

    Et zut, c'est pas le cas...

    Non, il ne s'agit pas d'un nouveau film de chuck norris
    On s'en fout, Steven Seagal is the best! Et lui au moins nous pond un ou deux film par an!

  • # Référence ?

    Posté par  . Évalué à 1.

    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.

    • [^] # Re: Référence ?

      Posté par  . Évalué à 4.

      L'article de silicon.fr dit:

      Aujourd’hui, la plupart des systèmes de fichiers adoptent des secteurs logiques de 4 ko (huit fois 512 octets) lorsqu’ils formatent un disque.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Référence ?

        Posté par  . Évalué à 3.

        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.

        • [^] # Re: Référence ?

          Posté par  (site web personnel) . Évalué à 3.

          Il faut faire attention que le filesystem soit bien aligné avec les blocks sur le disque, sinon chaque accès se paye double (bon le secteur n'est pas loin, c'est déjà ça) non?

          • [^] # Re: Référence ?

            Posté par  . Évalué à 4.

            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é.

            • [^] # Re: Référence ?

              Posté par  . Évalué à 6.

              Moi je parle de problème de consistance

              → « Cohérence » (faux-ami inside).

              • [^] # Re: Référence ?

                Posté par  . Évalué à 5.

                Lui aussi: il fait bien référence aux disques durs

                --------------> [ ]

  • # 4096 o !

    Posté par  (site web personnel) . Évalué à 3.

    Pas mal comme taille, mais il faudra bien un jour jouer avec la taille des "zones" des SSD qui sont autour de 128K. La différence avec un secteur, c'est la possibilité d'écrire une zone vierge par morceau.

    Si cela n'est pas gérer, on aura toujours le problème de fragmentation qui fait chuter les perfs (sauf sur les mtron, mais je ne sais pas pourquoi).

    "La première sécurité est la liberté"

    • [^] # Re: 4096 o !

      Posté par  . Évalué à 3.

      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.

      • [^] # Re: 4096 o !

        Posté par  . Évalué à 1.

        tu peux m'expliquer la fragmentation dans les ssd ?
        pour un disque dur si les cluster sont eloignés physiquement on peut comprendre la perte de temps, la je vois pas

        • [^] # Re: 4096 o !

          Posté par  . Évalué à 3.

          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.

      • [^] # Re: 4096 o !

        Posté par  (site web personnel) . Évalué à 4.

        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.

        Un "TRIM", c'est juste un "erase" pour rendre le secteur vierge. La taille des zones peut être lu sur les SSD.

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

        "La première sécurité est la liberté"

        • [^] # Re: 4096 o !

          Posté par  . Évalué à 3.

          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 ...

          • [^] # Re: 4096 o !

            Posté par  (site web personnel) . Évalué à 2.

            Il y a le wear leveling souvent mal fait, j'ai entendu parlé de sous -bloc de 4Mo. C'est souvent une sorte de hack pour éviter une vrai pagination.
            C'est un premier problème.

            Vient ensuite la gestion des zones. Une zone peut prendre 1s pour s'effacer. Donc, si il y a des écritures contigües sur des zone non vierge, il est plus rapide de recopier le tout dans un bloc vierge. C'est cette copie qui dégrade les performances. Si il n'y a plus de bloc libre, c'est encore pire avant de finir l'écriture il faut lancer un erase super lent.

            Lancer le TRIM en avance permet de libérer en avance des blocs pour éviter le cas pathologique.

            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.

            "La première sécurité est la liberté"

            • [^] # Re: 4096 o !

              Posté par  . Évalué à 2.

              (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).

  • # Maintenant tu sais

    Posté par  . Évalué à 7.

    constituent toujours le goulet (ou goulot je sais jamais) d'étranglement
    On dit plutôt "goulot" d'étranglement. Même si "goulet" est toléré. car il s'agit d'un terme de la marine[1] qui désigne un passage étroit dans une rade.

    1 http://fr.wikipedia.org/wiki/Goulet_d%27%C3%A9tranglement

    Bon, et sinon : les OS sont-ils tous prêts ? Pour Linux, ça a l'air d'aller mais pour Windows ? Et tout particulièrement les vieux Windows (2000/XP), qui sont toujours très utilisés, et qui pourraient cafouiller en cas de changement de disques durs...

    • [^] # Re: Maintenant tu sais

      Posté par  . Évalué à 4.

      D'après l'article de silicon.fr:

      Ce procédé est compatible avec Windows Vista, Windows 7 et Mac OS X. Pour Windows XP, Paragon fournit un utilitaire qui permettra de corriger le problème d’alignement des partitions. Western Digital ne précise pas si cette technologie est compatible avec Linux, mais il convient de noter que le disque peut aisément basculer en mode de compatibilité.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Maintenant tu sais

      Posté par  (site web personnel) . Évalué à 9.

      >>> Bon, et sinon : les OS sont-ils tous prêts ?

      Pour Linux c'est entré dans le 2.6.31.
      Voir ici : https://linuxfr.org//2009/09/10/25848.html#iotopology

    • [^] # Re: Maintenant tu sais

      Posté par  (site web personnel) . Évalué à 9.

      On dit plutôt "goulot" d'étranglement. Même si "goulet" est toléré. car il s'agit d'un terme de la marine[1] qui désigne un passage étroit dans une rade.

      Mouais, bof.

      Les deux sont deux diminutifs de «goule ». « Goulet » semble un peu plus vieux et désigne à l'origine un ruisseau (1358), puis prend le sens plus général d'« ouverture étroite ». Il désigne le col d'une bouteille en 1544 mais est vieilli par «goulot » pour cette acceptation dès le XVIIe. Quant à goulot, il veut dire en 1415 « passage où l'eau s'écoule », mais n'est maintenant employé dans cette acceptation que dans « goulot d'étranglement » comme métaphore du col d'une bouteille... (alors que « goulet d'étranglement » existe aussi hein ;-)).

      Source : dictionnaire historique de la langue française.

      Bref, c'est le même mot, « goulet » semble plus vieux.
      Les deux sont utilisés dans l'expression « goulet/goulot d'étranglement ».. sauf que pour « goulot » c'est en pensant au col d'une bouteille alors que c'est plutôt le sens général de « passage étroit par où s'écoule l'eau » qui est le sens original de l'expression (et donc celui de goulet à l'heure actuelle).

  • # Et un firmware ?

    Posté par  . Évalué à 3.

    Et un firmware configurable ???
    Histoire de mettre le bloc dans un multiple de 512 choisi (après un reformatage bas niveau, comme les vieux mfm) au lieu de voir dans 4ans une nouvelle évolution à 8...16Ko....

    • [^] # Re: Et un firmware ?

      Posté par  . Évalué à 2.

      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.

      • [^] # Re: Et un firmware ?

        Posté par  . Évalué à 4.

        C'est surtout adapté aux taille de page mémoire si j'ai bien compris qui ne sont pas prête de changer.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Et un firmware ?

          Posté par  (site web personnel) . Évalué à 3.

          La taille des pages mémoires est déjà assez variable, notamment grâce aux Large Pages (de quelques Mo jusqu'au Go !). Je ne suis pas sûr que le mapping 1-1 soit forcément adapté aux disques.

  • # 4 ko ?

    Posté par  (site web personnel) . Évalué à 0.

    des blocs de 4000 octets ? (bin oui un disque dur de 500 Go c'est bien 500 000 000 000 octets alors ...)

    enfin ça y est, les tailles de secteurs s'alignent sur des sous multiples de tailles de disque, c'est pas trop tôt ! même si j'aurais préféré 4 kio, c'est plus en phase avec les Rams qui fonctionnent encore en unités désuètes de puissance de 2 :-p

    • [^] # Re: 4 ko ?

      Posté par  . Évalué à 5.

      Brainfuck. It's worth it.

    • [^] # Re: 4 ko ?

      Posté par  . Évalué à -2.

      Ou t'as vu qu'ils parlaient de 4000 octets?

      Au cas où, 1Ko=1 024o, donc 500Go=536 870 912 000o... Enfin bon, si c'était de l'humour, ja pas compris :(

      • [^] # Re: 4 ko ?

        Posté par  . Évalué à 5.

        Normalement, 1024 octets ça s'appelle désormais un Kio, et plus un Ko. Le Ko vaut maintenant exactement 1000 octets, pour rester cohérent avec le SI. L'ennui c'est qu'effectivement, personne n'utilise cette nouvelle notation à part les fabricants de disques durs, qui trouvent fort pratique de vendre 1000 octets au prix de 1024. Donc on pouvait légitimement s'attendre à ce que leurs "blocs de 4K" soient des blocs de 4000 octets.

        • [^] # Re: 4 ko ?

          Posté par  (site web personnel) . Évalué à 2.

          personne n'utilise cette nouvelle notation à part les fabricants de disques durs

          Il y a les fabricants de DVD vierges aussi. Alors qu'un CD-R 700 Mo a une bien une capacité d'environ 700*2^20 octets, un DVD-R 4,7 "Go" fait plutôt dans les 4,3*2^30 octets. On peut admirer la cohérence.

          Sinon je confirme que mon message original était plutôt de l'ordre du sarcastique, car si les fabricants de disques durs étaient cohérents avec eux-mêmes, ils ne mélangeraient pas les unités "puissance de 10" (un disque 500 Go = 500*10^9 octets) et les puissances de 2 (secteurs de 4*2^10 octets).

          Bref, quand les commerciaux s'en mêlent, on se retrouve avec un système d'unités pas compatibles entre elles, et ça n'aide pas Madame Michu à y voir plus clair tout ça.

          • [^] # Re: 4 ko ?

            Posté par  (site web personnel) . Évalué à 2.

            Ah oui j'oubliais, les fabricants de cartes mémoire flash font pareil aussi.

            Vous allez voir, bientôt ça va être les RAMs ... (ils vendent bien des pécés avec 3 Go de ram !)

            • [^] # Re: 4 ko ?

              Posté par  (site web personnel) . Évalué à 2.

              enfin je voulais dire "3 Gio", bien sûr (enfin j'espère)

              • [^] # Re: 4 ko ?

                Posté par  . Évalué à 4.

                C'est quoi le problème. J'ai déjà eu un pc avec 80Mio de RAM et il tourne très bien

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: 4 ko ?

        Posté par  (site web personnel) . Évalué à 3.

        Euh non, relis bien son commentaire, il dit : « même si j'aurais préféré 4 kio». Si tu fais abstraction de la faute, il fait bien la différence entre 1 ko = 1000 o et 1kio = 1024 o.

        • [^] # Re: 4 ko ?

          Posté par  . Évalué à 2.

          Diantre, c'est vrai que je suis de la vieille école, qui dit que ko = kilo octet et que pour des raisons mathématiques évidentes propres à l'informatique et à l'électronique, 1kilo octet = 1024 octets.

          J'avais oublié cette notation à la con de kio. C'est vraiment une décision débile, n'ayant que pour objet de nous truander sur l'espace disque...

          Du coup, effectivement, le commentaire est pertinent.

          • [^] # Re: 4 ko ?

            Posté par  . Évalué à 5.

            Diantre, c’est vrai que je suis de la vieille école¹, qui dit que ko = kilo octet et que pour des raisons mathématiques évidentes propres à l'informatique et à l'électronique, 1kilo octet = 1000 octets².

            J'avais oublié cette prétention à la con des informaticiens de vouloir faire à leur manière, c'est vraiment une décision débile.

            ¹ Système_international_d'unités
            ² Préfixe_du_système_international

  • # La révolution...

    Posté par  . Évalué à 1.

    ... ce n'est pas Windows Mobile 7 présenté hier. J'ai failli y croire, pourtant.

    Car le titre m'a fait vraiment penser au journal d'annonce ironique de l'iPad lu ici. Mais bon, c'était improbable qu'un fanboy MS publie une telle news içi.

    • [^] # Re: La révolution...

      Posté par  . Évalué à 3.

      Microsoft a deja suffisemment de publicite gratuite faite par les medias traditionnels sans que l'on vienne en rajouter ici non?

    • [^] # Re: La révolution...

      Posté par  . Évalué à -2.

      passke cété ironik ? LOL

  • # Sauf qu'on nous dit que Linux n'est pas prêt

    Posté par  . Évalué à 3.

    Article de OSNews : http://www.osnews.com/story/22872/Linux_Not_Fully_Prepared_f(...)

    En gros ces disques c'est bien mais il faut que tout soit bien "aligné" sinon ça coince...

    Voir aussi : http://www.macbidouille.com/news/2010/02/16/le-nouveau-syste(...)

  • # Porte nawak

    Posté par  (site web personnel) . Évalué à 6.

    Ce que vient de faire WD, c'est n'importe quoi. Ils ont fait le travail à moitié :
    – en passant les blocs physiques à 4 kio ;
    – en exposant de façon mensongère des blocs de 512 o.

    Résultat, on doit faire attention à aligner ses systèmes de fichiers sur des blocs exposés multiples 8. Les outils de partitionnement ne sont évidemment pas prêts pour ça !

    À côté de ça, ils auraient pu exposer directement leurs blocs de 4 kio. Là, plus de problème, les outils de partitionnement seraient, selon leur cas :
    – franchement inadaptés, et refuseraient de partitionner ;
    – adaptés, et partitionneraient normalement en LBA, avec des adresses de blocs libres…

    • [^] # Re: Porte nawak

      Posté par  (site web personnel) . Évalué à 4.

      En faisant quelques recherches sur ce sujet des blocs de 4096 octets, il apparait que nombre de disques SSD utilisent déjà cette taille de bloc physique. Il est donc en effet étrange que WD ait implémenté ce "hack" dans ces disque durs, car après tout, les constructeurs de SDD ne le faisant pas, les solutions pour chaque OS fleurissent sur le web.

      D'ailleurs cette histoire peut expliquer les quelques témoignages d'utilisateurs de SDD trouvant leur nouveau disque peu performant. Leurs partitions étant certainement non-alignés avec les blocs physiques du disque.

      • [^] # Re: Porte nawak

        Posté par  . Évalué à 2.

        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.

  • # Formatage bas niveau

    Posté par  (site web personnel) . Évalué à 6.

    Je crois sans trop me tromper que la taille des blocs est définie lors du formatage dit "de bas niveau" du périphérique. En sortie d'usine, le disque est complètement vierge, il n'y a pas de cylindres ni de secteurs dessus. Il faut passer par une étape préliminaire qui est le formatage de bas niveau.

    Après bien sûr il faut que toute la chaîne soit prévue pour les blocs de 4kio, en commençant par la carte contrôleur embarquée sur le HDD (qui jusqu'à y'a pas longtemps géraient une taille fixe de 512 octets, d'où la limitation "physique"), puis le controleur sur le pécé (mais là, ça doit être plus gérable, les contrôleurs étant déjà capables de gérer des tailles de blocs diverses de type CD, DVD (2048 ou 2352 octets entre autres suivant les modes)), ou SSD apparemment.

    Donc bref, pour en revenir au formatage de bas niveau, ne serait-il pas judicieux que l'utilisateur (enfin, l'administrateur) puisse formater le disque avec la taille de bloc qui lui chante le mieux ? Ou est-ce que 4 kio should be enough for everyone ?

    • [^] # Re: Formatage bas niveau

      Posté par  . Évalué à 1.

      Tu veux pouvoir faire du formatage bas niveau sur des disques durs ayant des capacites de Tetraoctets?

      Mes souvenirs du temps ou cela se faisait encore sur des disques durs ayant des tailles absolument gigantesques (1 a 2 Giga) cela prenait 1 ou 2 jours entiers...

      • [^] # Re: Formatage bas niveau

        Posté par  . Évalué à 0.

        J'imagine que tu parles d'un zero filler plus que d'un formatage bas niveau. C'est d'ailleurs agaçant cette attirance qu'ont les gens pour le "formatage bas niveau".

        Pour le zero filler, si on considère une vitesse moyenne de 100 Mo/s sur toute la surface du disque (estimation assez crédible pour les disques durs actuels ), ça ferait 6 Go par minute, et donc 160 à 170 minutes par To. 3 heures en gros pour 1 To.

  • # Je n'ai rien compris à ce journal

    Posté par  . Évalué à -7.

    Je n'ai rien compris à ce journal, parce que comme les informaticiens devraient le savoir, les unités pour exprimer une quantité d'information binaire sont les octets.

    Ce journal parle de 4ko comme étant 4096 octets. Mais il n'en est rien ! 4ko, c'est 4000 octets. Et je ne vois pas l'intérêt de définir des blocs physiques de cette taille. Normal, il n'y en a pas.

    Par contre, 4 Kio, oui, ça je comprends. Mais quand même, ce serait sympa à ce niveau d'utiliser des unités adaptées. Voir :

    http://fr.wikipedia.org/wiki/Octet

    Parce que là, c'est franchement inconsistant le journal + les commentaires, plus personne ne sait qui dit quoi.

    Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

    • [^] # Re: Je n'ai rien compris à ce journal

      Posté par  . Évalué à 4.

      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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.