Contenu | Rechercher | Menus

Annonce

T-shirt Seiche Cosmic, Série limitée

L'équipe des administrateurs et modérateurs du forum vous invite à prendre connaissance des nouvelles règles.
En cas de besoin, vous pouvez intervenir dans cette discussion.

Ubuntu 18.10
T-shirt Ubuntu-FR « Seiche Cosmique » en série limitée ! Prix spécial pré-vente (15€) jusqu'au 4 novembre 2018.

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 25/12/2014, à 03:30

moko138

[Résolu] Taille des secteurs 512 / 4096 octets

Comme plusieurs fils font état de secteurs de 4096 octets moins bien reconnus que les secteurs de 512 octets, j'aimerais savoir :
- si cette taille est déterminée par le micrologiciel de chaque disque,
- ou bien si on peut la modifier à l'occasion d'un formatage.
                Et dans cette éventualité, avec quel outil.
  Merci d'avance !

Dernière modification par moko138 (Le 26/12/2014, à 09:28)


%NOINDEX%
Un utilitaire méconnu : ncdu

Hors ligne

#2 Le 25/12/2014, à 16:46

berserk

Re : [Résolu] Taille des secteurs 512 / 4096 octets

salut
Gparted  peut gérer ce type de disque sans problème.

Hors ligne

#3 Le 25/12/2014, à 17:22

moko138

Re : [Résolu] Taille des secteurs 512 / 4096 octets

Gparted  peut gérer ce type de disque sans problème.

Je te remercie, berserk, mais je ne vois pas le rapport entre ta réponse et ma question.
Veux-tu dire qu'il existerait, m'ayant échappé jusqu'à présent, un sous-menu de gparted permettant de modifier la taille des secteurs, à l'occasion d'un formatage complet ?


%NOINDEX%
Un utilitaire méconnu : ncdu

Hors ligne

#4 Le 25/12/2014, à 17:43

tiramiseb

Re : [Résolu] Taille des secteurs 512 / 4096 octets

Salut,

La taille du secteur est directement dépendante du matériel.
http://fr.wikipedia.org/wiki/Secteur_de_disque

Je doute qu'on puisse, de manière logicielle, la redéfinir.

Hors ligne

#5 Le 25/12/2014, à 22:26

berserk

Re : [Résolu] Taille des secteurs 512 / 4096 octets

Comme tiramiseb l'a dit, la taille des secteurs est physique elle ne change pas.
Pour Gparted tu n'as aucune manip de spéciale à faire pour formater et partitionner ton disque, tu fais comme d'ahabitude.

Hors ligne

#6 Le 25/12/2014, à 22:33

moko138

Re : [Résolu] Taille des secteurs 512 / 4096 octets

Merci, sagace d'Alsace !


%NOINDEX%
Un utilitaire méconnu : ncdu

Hors ligne

#7 Le 25/12/2014, à 22:36

J5012

Re : [Résolu] Taille des secteurs 512 / 4096 octets

d'autant que la facon algorithmique poussée de linux à gerer ces blocs au travers de plusieurs formats : ext4, reiser4, btrfs, zfs ... , n'est pas influencée par la taille comme sous w ...

Hors ligne

#8 Le 26/12/2014, à 09:26

moko138

Re : [Résolu] Taille des secteurs 512 / 4096 octets

tiramiseb a écrit :

La taille du secteur est directement dépendante du matériel.
http://fr.wikipedia.org/wiki/Secteur_de_disque

Je doute qu'on puisse, de manière logicielle, la redéfinir.

J'ajoute l'adresse d'un cas de secteur de 4096 o problématique ./viewtopic.php?id=1746491&p=1
et j'en ajouterai d'autres quand je les retrouverai.

Je note, au moins provisoirement,
- d'éviter de panacher les disques à taille de secteurs différentes sur un pc,
- d'éviter l'achat de HD à secteurs de 4096 o.


%NOINDEX%
Un utilitaire méconnu : ncdu

Hors ligne

#9 Le 26/12/2014, à 11:31

Gaara

Re : [Résolu] Taille des secteurs 512 / 4096 octets

Salut,

tiramiseb a écrit :

Je doute qu'on puisse, de manière logicielle, la redéfinir.

Je crois qu'en NTFS on peut avec Windox. Je me rappelle l'avoir redéfini sur un disque qui contenait beaucoup de fichiers <4096 o (carte type google map que j'avais téléchargé, ~ 10Go), et ça prenait beaucoup moins de place quand j'ai redéfini le disque à 512 o.  (voir ici par ex.)
Car avec 4096 o, chaque fichier inférieur à cette taille prend obligatoirement 4096 o sur le disque.
L'inconvénient est la rapidité de lecture.

Pour l'Ext4, je ne sais pas, je ne m'étais pas encore mis à Ubuntu tongue

Dernière modification par Gaara (Le 26/12/2014, à 11:32)


Kubuntu 16.10 x64
Une tablette Raspberry Pi et Odroid
Téléchargement de vidéo Pluzz et C+
                                        <code>zenity  --question --title "Alert"  --text "Microsoft Windows has been found! Would you like to remove it?"</code>

Hors ligne

#10 Le 26/12/2014, à 11:32

tiramiseb

Re : [Résolu] Taille des secteurs 512 / 4096 octets

Peut-être une incompatibilité entre le MBR et les disques à secteurs de 4ko.

Les disques à 4ko ça existe depuis longtemps, mais ils présentent des secteurs logiques de 512o au système pour raison de compatibilité.

Peut-être que des disques ne présentant plus ces 512o commencent à sortir, en se disant que ça fonctionne en EFI/GPT et tant pis pour BIOS/MBR.
Peut-être qu'il faut faire gaffe à ça.

J'ai trouvé la discussion suivante sur ce sujet, ça me semble intéressant :
http://superuser.com/questions/679725/h … ector-disk
(surtout la première réponse, écrite par Rod Smith)

Hors ligne

#11 Le 26/12/2014, à 11:51

tiramiseb

Re : [Résolu] Taille des secteurs 512 / 4096 octets

Gaara a écrit :

Je crois qu'en NTFS on peut avec Windox. Je me rappelle l'avoir redéfini sur un disque qui contenait beaucoup de fichiers <4096 o

Attention à ne pas confondre la taille des secteurs du disque et la taille des blocs (ou clusters) du système de fichiers.
http://fr.wikipedia.org/wiki/Bloc_%28disque_dur%29

On peut avoir un FS avec des blocs de 4Ko sur un disque avec des secteurs de 512o.

Gaara a écrit :

L'inconvénient est la rapidité de lecture.

Ainsi que, parfois, la taille maximale du système de fichiers : c'est parfois en nombre de blocs que cette taille maximale est définie, donc si les blocs sont plus petits la taille maxi est plus petite.
Par exemple en FAT32, des blocs de 4ko permettent une taille max de 1 Tio, des blocs de 8kio permettent une taille max de 2 Tio : en FAT32, l'adressage se fait sur 28 bits ; 2^28 = 268435456 ; 268435456×4kio = 1 Tio. En NTFS ainsi que ext3/4, l'adressage se fait sur 32 bits : avec des blocs de 4kio on peut aller jusqu'à 16 Tio, avec des blocs de 512o le FS ne peut pas dépasser 2 To. Avec ext4, on peut activer un adressage sur 48 bits, mais il semble que la stabilité et le support ne soient pas au rendez-vous.

Hors ligne

#12 Le 26/12/2014, à 12:07

Gaara

Re : [Résolu] Taille des secteurs 512 / 4096 octets

Ah d'accord je comprend mieux. Merci pour ces infos.


Kubuntu 16.10 x64
Une tablette Raspberry Pi et Odroid
Téléchargement de vidéo Pluzz et C+
                                        <code>zenity  --question --title "Alert"  --text "Microsoft Windows has been found! Would you like to remove it?"</code>

Hors ligne

#13 Le 04/04/2015, à 15:27

L_d_v_c@

Re : [Résolu] Taille des secteurs 512 / 4096 octets

Bonjour, intéressant de comprendre ces bestioles …
Dans la suite, j'utilise les termes :
-secteurs de disques comme étant les zones laissant 512 octets à l'utilisateur, sans tenir comptes des codes de contrôles sur la surface magnétiques, les parités et toute la technologie de réductions d'erreurs,
-blocs étant un ensemble de 2^N secteurs. Les disques 4Kio seraient comme des disques offrant des blocs de 4096 octets (soient 8 secteurs de 512 octets).

tiramiseb a écrit :

Salut,

La taille du secteur est directement dépendante du matériel.
http://fr.wikipedia.org/wiki/Secteur_de_disque

Je doute qu'on puisse, de manière logicielle, la redéfinir.

ça dépend si on laisse les contrôleurs internes des disques durs gérer les secteurs ou si c'est géré par le SE (système d'exploitation) par émulation, temps CPU, ou contrôleurs sur cartes-mères ?
Qu'en est-il avec Windows et Linux (sans GNU je parle du noyau) ?

S'amuse-t-on à reprogrammer tout ça ? à laisser faire le matériel qui hérite des commandes SCSI [Small Computer System Interface en anglais, est un standard définissant un bus informatique reliant un ordinateur à des périphériques ou à un autre ordinateur] (puis importé dans IDE/Fast IDE/UDMA) ?

Les bus SCSI et IDE/Fast IDE/UDMA qui sont exploités permettent par exemple de :
-laisser le contrôleur de disque formater une partition selon les paramètres transmis et ça se débrouille tout seul 00,0000% CPU.
-possibilité de copier des zones vers d'autres emplacements sans utiliser le temps CPU, tout se fait sur le bus SCSI / (Fast)IDE / UDMA. Par exemple lancer la copie d'une partition d'un disque vers un autre disque uniquement à travers le SCSI ou  (Fast)IDE / UDMA sans utiliser le temps CPU, par un système de négociation sur les bus avec 00,0000% CPU.

Avec le SATA, il faut tout connecter à la carte-mère, ou à une carte fille (PCI express par exemple). Le contrôleur externe au disque prend le relais. Apparemment on ne peut pas mettre plusieurs unité SATA sur une nappe et laisser un protocole gérer tout ça.
Mais qu'ont-ils laissé comme commandes normalisées dans les contrôleurs SATA internes aux disques ? au moins la négociation de blocs et de rafales de blocs, et parfois les commandes NCQ pour disques durs et TRIM pour SSD.

berserk a écrit :

Comme tiramiseb l'a dit, la taille des secteurs est physique elle ne change pas.
Pour Gparted tu n'as aucune manip de spéciale à faire pour formater et partitionner ton disque, tu fais comme d'habitude.

Les secteurs ont longtemps été de taille 512 octets, et le simple fait qu'il y ait eu tous les problèmes d'alignements avec les disques 4k (4 Kio) laisse apparaître une question légitime : si le disque 4k n'était pas rétrocompatible et utilisable en 512, alors les secteurs de 4Kio seraient indivisible et forcément alignés ! non ?

moko138 a écrit :


Je note, au moins provisoirement,
- d'éviter de panacher les disques à taille de secteurs différentes sur un pc,
- d'éviter l'achat de HD à secteurs de 4096 o.

Normalement, ces limitations ne sont pas justifiées : On peut panacher les disques à taille de secteurs différentes, mais tu as pu relever que c'est mal implémenté. Par exemple le nombre de secteurs par piste évolue sur nos disques en fonction du rayon et ça ne gène pas quand c'est bien géré par les contrôleurs internes de disques (et oui c'est le cas. Preuve qu'il y a plus de secteurs vers la périphérie que vers le centre des plateaux : le débit varie entre le centre et la périphérie, c'est pour cela que les swap se mettent en périphérie).

Gaara a écrit :

Salut,

Je crois qu'en NTFS on peut avec Windox. Je me rappelle l'avoir redéfini sur un disque qui contenait beaucoup de fichiers <4096 o (carte type google map que j'avais téléchargé, ~ 10Go), et ça prenait beaucoup moins de place quand j'ai redéfini le disque à 512 o.  (voir ici par ex.)
Car avec 4096 o, chaque fichier inférieur à cette taille prend obligatoirement 4096 o sur le disque.
L'inconvénient est la rapidité de lecture.

Pour l'Ext4, je ne sais pas, je ne m'étais pas encore mis à Ubuntu tongue

Oui et non.
En 512, la table d'index des fichiers grossit, mais si un fichier fait 20000 blocs de 512, le disque dur de toute façon est équipé d'un mécanisme de préchargement, reflété par la taille des buffers mémoire des disques durs (8 Mio à 64 Mio en moyenne).
(pour information - Ça veut aussi dire que l'accès aux fichiers ne se ferait pas à la même vitesse s'il venait la mauvaise idée d'écrire les blocs à l'envers, rendant inutile le préchargement.)

tiramiseb a écrit :

Peut-être une incompatibilité entre le MBR et les disques à secteurs de 4ko.

Les disques à 4ko ça existe depuis longtemps, mais ils présentent des secteurs logiques de 512o au système pour raison de compatibilité.

Peut-être que des disques ne présentant plus ces 512o commencent à sortir, en se disant que ça fonctionne en EFI/GPT et tant pis pour BIOS/MBR.
Peut-être qu'il faut faire gaffe à ça.

J'ai trouvé la discussion suivante sur ce sujet, ça me semble intéressant :
http://superuser.com/questions/679725/h … ector-disk
(surtout la première réponse, écrite par Rod Smith)

Voilà, de toute façon il ne faut surtout pas adresser un disque 4k en émulation 512, ça fait une surcouche logicielle qui bouffe du temps machine et des débits utilisateurs.

Un disque 4k est mieux adressé en 4k (ou 4Kio × 2^n ; n>0), donc on évite le 512 logique sur un 4Kio, on ne perd pas forcément de la place (sauf cas présenté par Gaara, mais c'est rare), ainsi on évite les traductions d'adresses.

L'adressage sur 48 bits fonctionnait très bien il y a 18 ans tiramiseb. J'utilisais le trackdisk.device (32 bit depuis l'achat de l'ordinateur en 1993) mais une limite était à 4 Gio par partition, limitée à 2 Gio si tu ne voulais pas voir le 3ème Gio à -1 Gio (en 32 bits). La simple mise à jour en 1996 d'un seul fichier (trackdisk.device (ver. 32 bits) → trackdisk.device (ver. 64 bits) permettait d'adresser les disques dures 48 bits, et au delà puisque la taille adressage en trackdisk 64 bits est de 18,44 × 10¹⁸ octets (18,44 Eo - Exaoctets | soient 18446 Po - Pétaoctets | soient 18 446 744 To - Téraoctets | soient 18 446 744 073 Go - Gigaoctets)
Bref, avec ces ordinateurs de 1993 pouvait adresser le mode 48 bits des disques durs (limite théorique à 281,4749767×10¹² octets ~ 281 To - 281474 Go) et le mode 48 bits fonctionnait parfaitement en PATA/UDMA branché sur le Fast-IDE (2,7 Mo/s en  l'an 1998 avec un disque de 4 Go - et comme les commandes étaient optimisées en assembleur, c'était plus rapide, temps réel. 2,7 Mo/s sans carte-fille IDE/UDMA spécifique - juste les composants de base).

Et ça me fait bizarre de lire que le NTFS et ext3/ext4 n'adressent que sur 32 bits alors qu'en 1996 on adressait en 64 bits / 48 bits en pratique avec les disques grands publics.

tiramiseb a écrit :

Avec ext4, on peut activer un adressage sur 48 bits, mais il semble que la stabilité et le support ne soient pas au rendez-vous.

Je regarde les prix : autour de 300 € un ordinateur d'occasion de 1993 modifié avec processeur MC68030 à 28 MHz ou 50 MHz, des fois avec 16 Mio de RAM en plus des 2 Mio de RAM d'origine. C'est tentant.

moi a écrit :

exo-kernel ou non, la force de l'Amiga : temps réel ! Surtout : les commandes se comptent en centaines d'octets.

L'idée de l'Amiga : ce qui est fait doit être bien fait et disponible pour tous (la force des librairies) on ne programme pas deux fois la même chose.

Cet exemple résume le problème de Linux :
Filemaster est vraiment l'équivalent de mc (midnight commander sous GNU/Linux)

mc ←…→ Après cette opération, 6 029 ko d'espace disque supplémentaires seront utilisés.

http://aminet.net/util/dir/FileMaster2.0.lha ←…→ 43,6 ko une fois décompressé (Filemaster 2.0 est comme midnight commander)
Tout se fait à la souris pour Filemaster 2.0, je crois qu'on pouvait éditer des raccourcis clavier

Bref : 6 029 ko pour GNU/Linux et 43,6 ko pour Amiga pour faire la même chose.

L’exécutable de l'Amiga est 138 fois plus léger / rapide.

Pour conclure sur le message original :
que ce soient des secteurs en 512 ou 4096, il faut gérer les erreurs de lectures et écritures en interne des unités. La gestion d'erreur grossit proportionnellement à la taille des secteurs.

Je ne comprends pas où est le gain : peut-être cela a-t-il permis de simplifier cette surveillance des erreurs justement, ou d'améliorer les algorithmes NCQ, ou de réduire par 8 la taille des tables d'allocations de secteurs (512 → 4096).

Dernière modification par L_d_v_c@ (Le 24/03/2017, à 22:06)


Bogue -1 : Derrière chaque bogue se cache constamment la faille humaine.
Les programmes conçus par méthodes formelles ne bogueront JAMAIS et ils n'auront pas besoin de mise à jour corrective, puisque tout fonctionnera comme prévu.

Hors ligne