Lenteur disque neuf et récent (WD20EARS et autres)

Support Debian
#1

Salut
J’ai rien trouvé à ce propos dans les posts existants et le problème me semble assez important pour que je me lance.

Le symptôme: disque neuf monstrueusement lent (5MBps à travers le LAN)
J’ai remplacé un WD20EADS (Green, 2To, 32Mo cache) mourant par le nouveau modèle (64Mo de cache) pour me retrouver avec un débit moyen divisé par 6! :013

Vous aurez plus d’infos ici mais pour résumer: ce nouveau modèle utilise des secteurs de 4ko au lieu du traditionnel 512o et Linux n’aime pas du tout. Heureusement il y a une solution: aligner le début de la partition pour qu’elle démarre au bon endroit (comme pour les SSD). Je n’entre pas plus dans les détails de peur de dire une bêtise car je ne suis pas très fort avec les histoires de secteurs, LBA, etc.

La solution sur un disque vierge: après avoir créé la partition avec fdisk, passer en mode expert (“x”) et déplacer le début de la partition (“b”):

[code]#fdisk /dev/sdb
…/…
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-243201, default 243201):
Using default value 243201

Command (m for help): x

Expert command (m for help): p

Disk /dev/sdb: 255 heads, 63 sectors, 243201 cylinders

Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID
1 00 1 1 0 254 63 1023 63 3907024002 83
2 00 0 0 0 0 0 0 0 0 00
3 00 0 0 0 0 0 0 0 0 00
4 00 0 0 0 0 0 0 0 0 00

Expert command (m for help): b
Partition number (1-4): 1
New beginning of data (63-3907024064, default 63): 64

Expert command (m for help): p

Disk /dev/sdb: 255 heads, 63 sectors, 243201 cylinders

Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID
1 00 1 1 0 254 63 1023 64 3907024001 83
2 00 0 0 0 0 0 0 0 0 00
3 00 0 0 0 0 0 0 0 0 00
4 00 0 0 0 0 0 0 0 0 00
[/code]
Les valeurs qui nous intéressent sont bien évidement celles de la colonne “Start”, avant et après…

Et là j’ai retrouvé des débits normaux (30 à 40MBps à travers le LAN).
Apparemment cette taille de secteur de 4ko est plus économique pour le fabricant donc on peu imaginer que cela va se répandre de plus en plus…

Si quelqu’un de plus pointu veux apporter des précision/correction sur ce post, qu’il n’hésite pas.
A+

#2

Je suis pas sur mais tu peux redimensionner la taille des secteurs non ??

#3

Salut,
Très intéressant, merci.

Comment savoir si les disque (récents) qu’on a utilisent des secteurs de 4ko au lieu du traditionnel 512o ?
Je n’ai pas bien compris comment le gars dans son article à fait pour tester…

[quote]Note that I realize that all my testing is “quick and dirty,” but I’m just trying to demonstrate a point, not analyze it in painful detail.

1000 random aligned 4K writes consistently take between 7 and 8 seconds.
1000 random unaligned 4K writes consistently take between 22 and 24 seconds.[/quote]

#4

Si j’ai bien compris, le problème vient du décalage entre la taille des secteurs logiques et la taille physique des secteurs d’où le nom de l’astuce qui consiste à aligner les secteurs logiques sur les secteurs physiques…
@Mimoza:
Lorsque j’ai formaté la partition, j’ai eu ceci:

# mke2fs -j /dev/sdb1 mke2fs 1.41.12 (17-May-2010) Étiquette de système de fichiers= Type de système d'exploitation : Linux Taille de bloc=4096 (log=2) Taille de fragment=4096 (log=2)

Pourtant, de mémoire, il me semble que lorsque j’affiche les infos de la partitions j’ai des secteurs de 512o, je vérifierai ce soir…

Cela dit, je ne prétends pas que c’est la seule solution et tune2fs ou un autre outil permettent peut-être de résoudre ce problème de perf désastreuses en modifiant la taille des secteurs logiques… Juste que c’est une solution qui marche :smiley:

Ok j’aurai dû mettre “Une solution” et pas “La solution” dans mon post :wink:

@LOL: hier soir j’étais en train de chercher quand j’ai eu une panne du net donc pour le moment il n’y a qu’au moment de formater que j’ai vu l’info clairement affichée (voir ci dessus), je tacherai de trouver plus pratique :005

#5

Salut,

Attention, toucher à la taille des blocs n’est pas sans conséquence sur la perte de capacité. Un petit fichier ne peut faire moins d’un bloc et si la taille des blocs est trop petite c’est le nombre de blocs qui est trop grand :slightly_smiling:

Ta première solution satisfait pleinement la logique, il me semble :slightly_smiling:

#6

Bon j’ai testé différents outils capables de récolter des infos à propos des disques (fdisk, smartctl, hdparm, hwinfo) mais aucune n’a renvoyé la fameuse taille de 4ko, pas même fdisk qui est pourtant supposé indiquer les tailles de secteur logique/physique :12

[code]# fdisk -l /dev/sdb

Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdb1 1 243201 1953512000+ 83 Linux
[/code]

Donc il n’y a qu’au moment du formatage que l’info apparait (peut-être qu’il faudra attendre de futurs kernels…)

#7

[quote=“Fatimon”]Bon j’ai testé différents outils capables de récolter des infos à propos des disques (fdisk, smartctl, hdparm, hwinfo) mais aucune n’a renvoyé la fameuse taille de 4ko, pas même fdisk qui est pourtant supposé indiquer les tailles de secteur logique/physique :12

[code]# fdisk -l /dev/sdb

Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdb1 1 243201 1953512000+ 83 Linux
[/code]

Donc il n’y a qu’au moment du formatage que l’info apparait (peut-être qu’il faudra attendre de futurs kernels…)[/quote]

Parce que c’est à ce moment là que la taille du bloc est décidée en fonction de la taille de la partition.
Ce n’est pas une notion qui dépend de la technologie du disque. Je sais, on a du mal à se défaire de la notion disque = partition que nous à collé dans le crane notre ami Billou

#8

Bon ben ca confirme ce que je disais dans mon premier post

Y’a un truc qui m’échappe encore :017
Merci pour tes lumières ggoodluck47… Je vais essayer de me trouver de la lecture pour approfondir la question :confused:

#9

vala un lien qui devrai a mon avis suffire a démmarer:

http://fr.wikipedia.org/wiki/Disque_dur#G.C3.A9om.C3.A9trie

#10

[quote=“Fatimon”]Bon ben ca confirme ce que je disais dans mon premier post

Y’a un truc qui m’échappe encore :017
Merci pour tes lumières ggoodluck47… Je vais essayer de me trouver de la lecture pour approfondir la question :confused:[/quote]

Le bloc comprend x secteurs de 512 et est la plus petite partie adressable d’une partition. Comme la table des blocs n’est pas extensible à l’infini, plus la partition est grande plus le nombre de secteurs par bloc est important :slightly_smiling:
Ouf :041

#11

Pour être franc: je comprend rien de vos message.
Ayant aussi 2 western digial 1000 gb, l’un 32 mb et l’autre 64 mb, je voudrais un peu plus de précision sur l’astuce.

#12

Salut

Déjà, as-tu des problèmes de lenteurs sur celui qui a 64Mo de cache? Et est-ce un Caviar Green? L’article anglais semble préciser que c’est ce modèle qui est concerné chez WD…

A+

#13

J’ai un maxtor 500 gb pour debian et 2 western (green) 1 terra, 32mb (ext4) et 64mb (ntfs) pour mes fichiers stockage.

[code]Si j’utilise debian sur maxtor:
maxtor > wester 1/2: aucun problème de copie
western 1/2 > maxtor: aucun problème de copie
western 1 > western 2: aucun problème de copie

Mais si j’utilise debian sur un western 1:
western 1 > western 2/maxtor: copie debute à la taille moyenne 40-50-60 mb, puis diminue jusqu’à 2-3-4-5 mb.[/code]

La conclusion est simple:
Si j’ai debian sur western digital et que je veux copier des fichiers sur un autre disque dur, c’est mort.

#14

Salut,

Vous devriez spécifier quel système de fichier vous utilisez, cela à son importance (journalisation, …)

#15

J’ai édité mon poste.

#16

Ca ressemble effectivement au problème d’alignement de partition donc tu pourrais tester la méthode indiquée dans le premier post (fdisk …, touche x, touche p pour vérifier que la 1ère partition démarre bien sur le 63e bloc, touche b puis numéro de partition et numéro du nouveau bloc de départ soit 64 et enfin w)…

attention: je n’ai pas de certitude quand au résultat pour les données se trouvant déjà sur le disque mais c’est sûrement pas terrible donc il faudrait les déplacer ailleurs avant ou utiliser un outil moins frustre que fdisk (gparted sait peut-être faire cela en préservant les données?)

#17

Effectivement ayant pas mes disque dur vide, je ne peux pas les toucher avec fdisk.

#18

tu peux les cloner avec dd ce qui supose que t’a un suport de stokage qui va bien.

il va te sauvgarde le disque tel qu’il est. ensuite tu peux tenter avec fdisk si sa foire tu restaure avec dd.
d’ailleur il me semble qu’on peux monter une image faite par dd concernant un clonage de disque ,cepandant j’ai pas vu de tuto en parler :unamused:

#19

Pour cloner un disque dur il faut quand même avoir de l’espace il me semble, car avec 1 terra disque dur et 900 gb de données sa va pas être facile.

Du moment que les fichiers sont hors de mon disque dur où je possède le système d’exploitation il n’y a pas de perte de vitesse.
Tous mes disque sont en utilisation, je penses les laisser comme elle sont, car je veux pas risquer mes fichiers.

#20

Bon ben je passe le fil en résolu sinon je vais me faire taper sur les doigts, même si initialement je l’avais mis dans T&A… :wink:

A+