Performance partition commençant à 1, 63 ou 2048

Quel alignement pour éviter des I/O inutiles Système et matériels / Installation et configuration

kalagani Membre non connecté

Le 10/04/2014 à 09h46

Bonjour,

devant faire un nouveau partitionnement sur un DD, je me pose la question de savoir quel est le meilleur alignement pour éviter des

pertes de performance quand le buffer de données à accéder est en frontière de cylindre/secteur, lequel impliquerait 2 accès DD au lieu d'1 si ce buffer de données n'avait pas été en frontière...

Dans un premier temps j'ai découvert qu'entre mon nouveau DD et mes anciens le début d'alignement secteur est différent:

2048 au lieu de 63

Caché :

kalagani :

1ère surprise ce DD (250Go) d'occase prépartitionné commence au secteur 2048

Code BASH :

Disk /dev/sda: 250.1 GB, 250059350016 bytes, 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xdfc5dfc5
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048    40962047    20480000   83  Linux
/dev/sda2        40962048    45058047     2048000   82  Linux swap / Solaris
/dev/sda3        45058048    86018047    20480000   83  Linux
/dev/sda4        86018048   488396799   201189376    5  Extended
/dev/sda5        86020096   126980095    20480000   83  Linux
/dev/sda6       126982144   488396799   180707328   83  Linux

alors que mes DD actuels commencent à 63

Code BASH :

fdisk -l
 
Disque /dev/sdb : 465,8 GiB, 500107862016 octets, 976773168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x000d47f1
 
Périphérique Amorçage    Début       Fin     Blocs  Id Système
/dev/sdb1    *               63   8401994   4200966  83 Linux
/dev/sdb2               8401995  33479459  12538732+ 83 Linux
/dev/sdb3              33479460  71328599  18924570  83 Linux
/dev/sdb4              71328600 976768064 452719732+  5 Extended
/dev/sdb5              71328663 773883179 351277258+  7 HPFS/NTFS/exFAT
/dev/sdb6             773883243 933280109  79698433+  b W95 FAT32
/dev/sdb7             933280173 976768064  21743946   7 HPFS/NTFS/exFAT
 
 
Disque /dev/sda : 74,5 GiB, 80026361856 octets, 156301488 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xd24bd24b
 
Périphérique Amorçage    Début       Fin    Blocs  Id Système
/dev/sda1    *               63  41929649 20964793+  7 HPFS/NTFS/exFAT
/dev/sda2              41929650 125821079 41945715   7 HPFS/NTFS/exFAT
/dev/sda3             125821080 156296384 15237652+ 83 Linux

alors après un premier partionnement avec fdisk de ce nouveau DD, une vérification par sfdisk -V me laissait dubitatif avec ses warnings sfdisk: Warning: extended partition does not start at a cylinder boundary.

Caché :

kalagani :

teutates :

...

Alignement ? C'est plutôt pour les SSD me semble-'il. Ce disque est un disque à plateaux (Western Digital Velociraptor) et ne pose aucun problème.

...

Alignement pas que pour les SSD, les DD dit "4K" y sont également sensibles,

quant aux notres plus anciens, il peut aussi y avoir perte de performance quand le buffer de données à accéder est en frontière de cylindre/secteur, alors il faudra 2 accès DD au lieu d'1 si ce buffer de données n'avait pas été en frontière, cf ici

Ci-dessous le résultat (qui m'inquiéte) d'un sfdisk -l -u S (équivalent au -V) sur mon partitionnement de mon nouveau DD250Go

Code BASH :

sfdisk -l -u S /dev/sda
sfdisk: Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
 
sfdisk:         end: (c,h,s) expected (1023,254,63) found (20,117,33)
 
sfdisk:         start: (c,h,s) expected (1023,254,63) found (20,117,34)
 
sfdisk:         end: (c,h,s) expected (1023,254,63) found (583,75,4)
 
sfdisk:         start: (c,h,s) expected (1023,254,63) found (583,75,5)
 
sfdisk:         end: (c,h,s) expected (1023,254,63) found (122,32,38)
 
sfdisk:         start: (c,h,s) expected (1023,254,63) found (122,32,39)
 
sfdisk:         end: (c,h,s) expected (1023,254,63) found (705,80,63)
 
sfdisk:         start: (c,h,s) expected (1023,254,63) found (122,65,8)
 
sfdisk:         end: (c,h,s) expected (1023,254,63) found (403,171,24)
 
sfdisk:         start: (c,h,s) expected (1023,254,63) found (403,203,57)
 
sfdisk:         end: (c,h,s) expected (1023,254,63) found (134,44,38)
 
sfdisk:         start: (c,h,s) expected (1023,254,63) found (134,77,8)
 
sfdisk:         end: (c,h,s) expected (1023,254,63) found (978,140,58)
 
sfdisk:         start: (c,h,s) expected (1023,254,63) found (978,173,28)
 
sfdisk:         end: (c,h,s) expected (1023,254,63) found (517,130,61)
 
sfdisk:         start: (c,h,s) expected (1023,254,63) found (517,163,31)
 
sfdisk:         end: (c,h,s) expected (1023,254,63) found (799,14,47)
 
sfdisk:         start: (c,h,s) expected (1023,254,63) found (799,47,17)
 
sfdisk:         end: (c,h,s) expected (1023,254,63) found (705,80,63)
 
 
Disk /dev/sda: 30401 cylinders, 255 heads, 63 sectors/track
Units: sectors of 512 bytes, counting from 0
 
   Device Boot    Start       End   #sectors  Id  System
/dev/sda1          2048  16779263   16777216  82  Linux swap / Solaris
/dev/sda2      16779264  58722303   41943040  83  Linux
/dev/sda3      58722304 100665343   41943040   7  HPFS/NTFS/exFAT
/dev/sda4     100665344 488397167  387731824   5  Extended
/dev/sda5     100667392 121638911   20971520  83  Linux
/dev/sda6     121640960 216012799   94371840   7  HPFS/NTFS/exFAT
/dev/sda7     216014848 278929407   62914560   7  HPFS/NTFS/exFAT
/dev/sda8     278931456 320874495   41943040  83  Linux
/dev/sda9     320876544 341848063   20971520  83  Linux
/dev/sda10    341850112 488397167  146547056  83  Linux

Croyant que le mieux était de s'aligner sur le cylindre, j'arrivais finalement à un résultat où le début d'alignement n'est plus ni à 63 ou 2048 mais maintenant à 1

Caché :

kalagani :

Code BASH :

fdisk -l /dev/sda
 
Disk /dev/sda: 250.1 GB, 250059350016 bytes, 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x1c921ac5
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1    16803989     8401994+  82  Linux swap / Solaris
/dev/sda2        16803990    58749704    20972857+  83  Linux
/dev/sda3   *    58749705   100695419    20972857+   7  HPFS/NTFS/exFAT
/dev/sda4       100695420   488392064   193848322+   5  Extended
/dev/sda5       100695421   121676309    10490444+  83  Linux
/dev/sda6       121676311   216058184    47190937    7  HPFS/NTFS/exFAT
/dev/sda7       216058186   278984789    31463302    7  HPFS/NTFS/exFAT
/dev/sda8       278984791   320930504    20972857   83  Linux
/dev/sda9       320930506   341911394    10490444+  83  Linux
/dev/sda10      341911396   488392064    73240334+  83  Linux

via un alignement cylindres par fichier en entrée de sfdisk

Code BASH :

/sbin/sfdisk /dev/sda < sfdisk_sda250.cmd

avec sfdisk_sda250.cmd

Code BASH :

cat sfdisk_sda250.cmd
,1046,82
,2611,83
,2611,7
,,E
,1306,83
,5875,7
,3917,7
,2611,83
,1306,83
,,83

et où surprise, malgré un sfdisk -V sans warnings

Caché :

sfdisk -V

/dev/sda : OK

un petit signe + en fin de partition m'indique que celles-ci ne se terminent pas sur un bloc!

La différence que je comprends entre 1, 63 et 2048:

_dans les 3 cas bien sûr, le 1er secteur est obligatoire pour le MBR (Master Boot Record)

_63 ou 2048 -> il y a un espace inutilisé de 62 ou 2047 secteurs pour les applications, mais "libre" pour d'éventuels boot manager tels que les Grub legacy ou Grub2...en complément d'une première partie en MBR

_1 -> espace optimisé pour les applications mais impossibilité d'utiliser ce MBR pour y placer une amorce quelconque de boot manager autre que celui du Windows installé en premier

En effet, Grub legacy, par ex, y place une partie de son stage1, et comme le MBR est trop petit (512 octets) le reste et la partie stage2 sont placés au delà de ce premier secteur ainsi on est condamné à utiliser le boot manager Windows quitte à le modifier pour pointer sur les boot manager Linux placés ici obligatoirement dans la partition / de chaque Linux respectif

(ce dernier cas est illustré ici ici: quadruble démarrage sans boot manager Linux en MBR) dont sont extraites les parties cachées de ce topic

où une recherche via dd dans les 2048 premiers secteurs ne montre aucune trace de grub:

Code BASH :

dd if=/dev/sda count=2048 2> /dev/null | xxd -c 40 |egrep -i 'grub|stage'
#

au contraire (autre PC) de ce double boot XP/Mageia avec Grub Legacy placé en MBR (de 0 à 1FF) et au delà

Caché :

Code BASH :

dd if=/dev/sda count=2048 2> /dev/null | xxd -c 40 |egrep -i 'grub|stage'
0000000: eb48 9000 0000 4752 5542 007c 89e6 fbfc bf00 06b9 0001 f2a5 e900 8abd be07 f6c2 8075 1db8 0102 bb00  .H....GRUB.|.....................u......
0000168: 0ebe 8a7d e838 00eb 06be 947d e830 00be 997d e82a 00eb fe47 5255 4220 0047 656f 6d00 4861 7264 2044  ...}.8.....}.0...}.*...GRUB .Geom.Hard D
00002f8: e837 00be 2321 e831 00eb fe4c 6f61 6469 6e67 2073 7461 6765 312e 3500 2e00 0d0a 0047 656f 6d00 5265  .7..#!.1...Loading stage1.5......Geom.Re
0000410: 0200 302e 3937 00ff ff01 812f 626f 6f74 2f67 7275 622f 7374 6167 6532 202f 626f 6f74 2f67 7275 622f  ..0.97...../boot/grub/stage2 /boot/grub/
0002210: 3266 7300 0a0a 4752 5542 206c 6f61 6469 6e67 2c20 706c 6561 7365 2077 6169 742e 2e2e 0a00 696e 7465  2fs...GRUB loading, please wait.....inte
0002238: 726e 616c 2065 7272 6f72 3a20 7468 6520 7365 636f 6e64 2073 6563 746f 7220 6f66 2053 7461 6765 2032  rnal error: the second sector of Stage 2

Alors ai je bien compris?

bien aligné?

Quel est le moyen de vérifier?

Merci

PS: la performance actuelle de ce DD 250Go sur ce PC (proc E5200/1Mo Ram) et ses caratéristiques via hdparm

Caché :

cf man: indication du débit du processeur, cache et mémoire du système testé

Code BASH :

hdparm -t -T /dev/sda
 
/dev/sda:
 Timing cached reads:   1974 MB in  2.00 seconds = 987.02 MB/sec
 Timing buffered disk reads: 220 MB in  3.03 seconds =  72.65 MB/sec
hdparm -I /dev/sda
 
/dev/sda:
 
ATA device, with non-removable media
        Model Number:       ST3250310AS                             
        Serial Number:      9RY4AZN3            
        Firmware Revision:  3.AHC   
Standards:
        Supported: 7 6 5 4 
        Likely used: 8
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:   16514064
        LBA    user addressable sectors:  268435455
        LBA48  user addressable sectors:  488397168
        Logical  Sector size:                   512 bytes
        Physical Sector size:                   512 bytes
        device size with M = 1024*1024:      238475 MBytes
        device size with M = 1000*1000:      250059 MBytes (250 GB)
        cache/buffer size  = 8192 KBytes
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 16
        Recommended acoustic management value: 208, current value: 0
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4 
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    DOWNLOAD_MICROCODE
           *    48-bit Address feature set
                Device Configuration Overlay feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
                Write-Read-Verify feature set
           *    WRITE_UNCORRECTABLE_EXT command
           *    {READ,WRITE}_DMA_EXT_GPL commands
           *    Segmented DOWNLOAD_MICROCODE
           *    Gen1 signaling speed (1.5Gb/s)
           *    Gen2 signaling speed (3.0Gb/s)
           *    Native Command Queueing (NCQ)
           *    Phy event counters
                Device-initiated interface power management
           *    Software settings preservation
           *    SMART Command Transport (SCT) feature set
           *    SCT Write Same (AC2)
           *    SCT Features Control (AC4)
           *    SCT Data Tables (AC5)
Security: 
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
                frozen
        not     expired: security count
                supported: enhanced erase
        54min for SECURITY ERASE UNIT. 54min for ENHANCED SECURITY ERASE UNIT. 
Checksum: correct

Édité par kalagani Le 12/04/2014 à 22h03

PC1: HPxw9400 Mageia8 Xfce/Cinnamon (ex Plasma car "Freeze")
PC2: Dell Studio 540 Core2 Quad Q8300 en double boot: XPsp3/Mageia8 64bits Plasma

kalagani Membre non connecté

Le 12/04/2014 à 23h37

#173664

kalagani :

Alors ai je bien compris?

bien aligné?

Quel est le moyen de vérifier?

En ce qu'il s'agit du MBR et de l'installation du Grub Legacy ou du Grub2 dedans ou pas, j'oserai dire presque complètement :+)

Quant au moyen de vérifier l'alignement, j'ai découvert l'option align-check de parted

Alors employé sur le DD commençant au secteur 1:

et bien normand ce parted,... car ça dépend de l'option choisie minimal ou optimal, dans un cas c'est aligné dans l'autre non!!!

Caché :

Code BASH :

(parted) unit GiB                                                         
(parted) print                                                            
Model: ATA ST3250310AS (scsi)
Disk /dev/sda: 233GiB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 
 
Number  Start    End      Size     Type      File system     Flags
 1      0.00GiB  8.01GiB  8.01GiB  primary   linux-swap(v1)
 2      8.01GiB  28.0GiB  20.0GiB  primary   ext4
 3      28.0GiB  48.0GiB  20.0GiB  primary   ntfs            boot
 4      48.0GiB  233GiB   185GiB   extended
 5      48.0GiB  58.0GiB  10.0GiB  logical   ext4
 6      58.0GiB  103GiB   45.0GiB  logical   ntfs
 7      103GiB   133GiB   30.0GiB  logical   ntfs
 8      133GiB   153GiB   20.0GiB  logical   ext4
 9      153GiB   163GiB   10.0GiB  logical   ext4
10      163GiB   232GiB   69.0GiB  logical
(parted) align-check                                                     
alignment type(min/opt)  [optimal]/minimal? minimal                       
Partition number? 1                                                       
1 aligned
(parted) align-check
alignment type(min/opt)  [optimal]/minimal? minimal                       
Partition number? 2                                                       
2 aligned
(parted) align-check minimal
Partition number? 3                                                       
3 aligned
(parted) align-check minimal 4                                            
4 aligned
(parted) align-check minimal 5
5 aligned
(parted) align-check minimal 6
6 aligned
(parted) align-check minimal 7
7 aligned
(parted) align-check minimal 8
8 aligned
(parted) align-check minimal 9
9 aligned
(parted) align-check minimal 10
10 aligned
align-check                                                      
alignment type(min/opt)  [optimal]/minimal?                               
Partition number? 1                                                       
1 not aligned
(parted) align-check                                                      
alignment type(min/opt)  [optimal]/minimal?                               
Partition number? 2                                                       
2 not aligned
(parted) align-check                                                      
alignment type(min/opt)  [optimal]/minimal?                               
Partition number? 3                                                       
3 not aligned
(parted) align-check                                                      
alignment type(min/opt)  [optimal]/minimal?                               
Partition number? 4                                                       
4 not aligned
(parted) align-check                                                      
alignment type(min/opt)  [optimal]/minimal?                               
Partition number? 5                                                       
5 not aligned
(parted) align-check                                                      
alignment type(min/opt)  [optimal]/minimal?                               
Partition number? 6                                                       
6 not aligned
(parted) align-check                                                      
alignment type(min/opt)  [optimal]/minimal?                               
Partition number? 7                                                       
7 not aligned
(parted) align-check                                                      
alignment type(min/opt)  [optimal]/minimal?                               
Partition number? 8                                                       
8 not aligned
(parted) align-check                                                      
alignment type(min/opt)  [optimal]/minimal?                               
Partition number? 9                                                       
9 not aligned
(parted) align-check                                                      
alignment type(min/opt)  [optimal]/minimal?                               
Partition number? 10                                                      
10 not aligned

Et c'est la même chose pour 2 autres DD commençant à 63, minimal OK, optimal NOK!!!

Par contre pour un DD commençant à 2048, l'alignement (pour parted) est bien sur minimal mais surtout aussi optimal.

Caché :

Code BASH :

fdisk -l /dev/sda
 
Disk /dev/sda: 40.0 GB, 40000000000 bytes, 78125000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x40000000
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048    34818047    17408000   83  Linux
/dev/sda2        34818048    38914047     2048000   82  Linux swap / Solaris
/dev/sda3        38914048    78123007    19604480   83  Linux
 
parted /dev/sda unit s print free
[?1034hModel: ATA ST340014AS (scsi)
Disk /dev/sda: 78125000s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 
 
Number  Start      End        Size       Type     File system     Flags
        63s        2047s      1985s               Free Space
 1      2048s      34818047s  34816000s  primary  ext3            boot
 2      34818048s  38914047s  4096000s   primary  linux-swap(v1)
 3      38914048s  78123007s  39208960s  primary  ext3
        78123008s  78124999s  1992s               Free Space
(parted) align-check min 1                                                
1 aligned
(parted) align-check min 2
2 aligned
(parted) align-check min 3
3 aligned
(parted) align-check opt 1                                             
1 aligned
(parted) align-check opt 2
2 aligned
(parted) align-check opt 3
3 aligned

Malgré tout sur ce DD complètement aligné à 2048, sfdisk -V relève un défaut d'alignement cylindre

Caché :

sfdisk /dev/sda -V

Warning: partition 1 does not end at a cylinder boundary

Warning: partition 2 does not start at a cylinder boundary

Warning: partition 2 does not end at a cylinder boundary

Warning: partition 3 does not start at a cylinder boundary

Warning: partition 3 does not end at a cylinder boundary

/dev/sda: OK

parted /dev/sda unit chs print

[?1034hModel: ATA ST340014AS (scsi)

Disk /dev/sda: 4863,14,22

Sector size (logical/physical): 512B/512B

BIOS cylinder,head,sector geometry: 4863,255,63. Each cylinder is 8225kB.

Partition Table: msdos

Disk Flags:

Number Start End Type File system Flags

1 0,32,32 2167,82,26 primary ext3 boot

2 2167,82,27 2422,73,18 primary linux-swap(v1)

3 2422,73,19 4862,237,46 primary ext3

Ce que je crois comprendre,

_c'est que l'accès cylindres du CHS (Cylinder/Head/Sector), est abandonné (sauf premier secteur) au profit du LBA (Logical Block Addressing) , ainsi on peut ignorer les warning de sfdisk et que donc un alignement sur cylindre que je croyais judicieux semble obsolète...au moins pour Linux cf man fdisk de util-linux 2.24

Code TEXT :

DOS  uses C/H/S only, Windows uses both, Linux never uses C/H/S.  The C/H/S addressing is deprecated and may be unsupported in some later fdisk version.

_ainsi parted se moque de l'alignement cylindres dans son align-check minimal ou optimal

tous ces DD étant de taille secteur physique/logique=512 octets,

qu'ils commencent à 1, 63 ou 2048, il y aura toujours alignement minimal,

Par contre pour l'alignement optimal, cela ne sera jamais le cas pour 1 et 63, au sens et pour cette version de parted dans la mesure où celui-ci s'aligne (c'est le mot :+) sur les nouveaux DD dit Advanced Format, à taille physique de 4kio, cf cette explication et surtout sur les SSD...qui auraient un bloc (physique, logique?) de 1Mio soient les 2048 secteurs en question (2048x512=1048576octets)

Et que dans ce cas seul un alignement sur 2048 sera déclaré optimal par parted!

Je comprend aussi que les DD trouvés alignés à 63 ont été formaté avec d'anciennes versions de fdisk ou autre mais qu'aujourd'hui ils le seraient sur 2048! cf ici

Caché :

avec le fdsik de util-linux-2.24-2.mga4

Code BASH :

...Utilisation de la réponse p par défaut.
Numéro de partition (1-4, 1 par défaut) : 
Premier secteur (2048-8275967, 2048 par défaut) : 1
Valeur hors limites.
Premier secteur (2048-8275967, 2048 par défaut) : 63
Valeur hors limites.
Premier secteur (2048-8275967, 2048 par défaut) : 64  
Valeur hors limites.
Premier secteur (2048-8275967, 2048 par défaut) : 128 
Valeur hors limites.

Cet alignement à 63 était et reste adapté pour XP et les anciens Linux...

Avec une nouvelle version de fdisk, il semblerait que l'usage de l'option -c=dos permette de retrouver un début à 63...

Alors à quoi bon aligner sur 2048, si l'on ne prévoit ni l'achat de SSD ni de DD 4K puisque l'inconvénient est de perdre un peu plus de secteurs encore (de 63 à 2048) en début de DD!?

Et bien peut-être à cause des systèmes de fichier "modernes" genre ext4 dont le bloc n'est plus de 512 mais oscille entre 1024, 2048 ou 4096...

Et bien pour les vieux DD et même pour les DD 4K, NON à la dictature du 2048 et des SSD,

car commencer à 2048 n'est à faire que pour les partitions situées sur ces SSD, et si pas de SSD on s'en fout :+)!

D'ailleurs, ici, y a même un mec qui soutient que c'est un gros pipeau...dont je vous laisse seul juge...

Citation :

The only reason for preferring 1MiB alignment to the smaller 4KiB alignment that the hardware actually needs is simply that it means that tools that display disc partition locations and lengths in terms of MiBs get to display whole numbers. Or, in other words, measuring partition placements and sizes in units of KiB is unnecessarily precise for users that are not themselves generally working in units smaller than GiBs when they are partitioning discs.

Bon, il est vrai nul trace de SSD dans cet article...

Ben et les systèmes de fichiers "modernes" me direz vous!

Réponse: puisqu'ils doivent être alignés sur un multiple de 4Kio, alignons les sur 64,

ainsi respect de l'historique 63 et y aura moins de secteurs inutilisés qu'à 2048:

en effet n'oublions pas que si on ne met aucun Grub dans le MBR, on perd 2048-1 sur la 1ère primaire mais aussi 2048-1 pour chaque partition logique (le 1 c'est ici pour l'EBR=Extended Boot Record)...alors autant ne perdre que 64-1 à chaque fois, non?

Édité par kalagani Le 12/05/2014 à 22h50

PC1: HPxw9400 Mageia8 Xfce/Cinnamon (ex Plasma car "Freeze")
PC2: Dell Studio 540 Core2 Quad Q8300 en double boot: XPsp3/Mageia8 64bits Plasma

kalagani Membre non connecté

Le 26/04/2014 à 13h00

#174493

Hello,

kalagani :

Alors ai je bien compris?

bien aligné?

Quel est le moyen de vérifier?

Bien beau de croire comprendre MBR, Grubs et que les derniers outils de partitionnement (fdisk, parted entre autres) alignent systématiquement (abusivement???) sur 2048, encore faut il vérifier une amélioration du nombre d'accès I/O entre partitions pas alignées et alignées...

Alors je me suis mis à fouiller encore Internet...pour finir par m'arrêter sur les 2 outils que sont hdparm (déjà cité) et dd...rien de trop nouveau à l'Ouest du Pecos me direz vous, mais il m'a fallu épicer ceux-ci avec du blockdev --flushbufs et --report pour la mise en oeuvre :+)

hdparm: (lecture)

déjà vérifier que le disque n'est pas freiné par le choix d'acoustique...si, si...

Code BASH :

hdparm -M /dev/sdb
/dev/sdb:
 acoustic      = 254 (128=quiet ... 254=fast)

ben oui, à quoi bon gagner de la milliseconde avec un alignement aux petits oignons si l'on ne veux pas entendre une mouche dans son PC...

puis pour test lecture appliquer les options -T et -t semble possible à la fois sur le DD mais aussi sur chaque partition

Code BASH :

hdparm -Tt /dev/$part

la plus réelle étant le résultat de -t par accès direct au DD alors que -T l'est via le cache (du moins je le comprend comme cela.

Code BASH :

/dev/sdb1:
 Timing cached reads:   2280 MB in  2.00 seconds = 1139.86 MB/sec
 Timing buffered disk reads: 398 MB in  3.01 seconds = 132.35 MB/sec
 
/dev/sdb2:
 Timing cached reads:   2382 MB in  2.00 seconds = 1191.18 MB/sec
 Timing buffered disk reads: 400 MB in  3.01 seconds = 132.93 MB/sec
 
/dev/sdb3:
 Timing cached reads:   2470 MB in  2.00 seconds = 1234.87 MB/sec
 Timing buffered disk reads: 394 MB in  3.01 seconds = 130.87 MB/sec

dd: (lecture)

Bien beau cela, mais qu'emploie donc hdparm comme blocs et comme taille de ceux-ci pour son test?

Alors j'ai pinaillé en créant avec dd mes propres bloc/taille avec bs et count

Code BASH :

dd if=/dev/sdb1 of=/dev/null  bs=1M count=100 skip=0
100+0 enregistrements lus
100+0 enregistrements écrits
104857600 octets (105 MB) copiés, 0,77635 s, 135 MB/s
dd if=/dev/sdb1 of=/dev/null bs=1M count=100 skip=0
100+0 enregistrements lus
100+0 enregistrements écrits
104857600 octets (105 MB) copiés, 0,0869069 s, 1,2 GB/s
dd if=/dev/sdb1 of=/dev/null bs=1M count=100 skip=0
100+0 enregistrements lus
100+0 enregistrements écrits
104857600 octets (105 MB) copiés, 0,0848765 s, 1,2 GB/s

et c'est là que j'ai commencé à épicer car après une première lecture plausible le résultat des suivantes s'avéraient comme optimiste au delà du réel...quand on sait qu'il y a peu de chance de dépasser les 200MB/sec et qu'on mesure 1,2GB/sec!!!!

En effet je croyais faire des lectures directes via dd, mais il semble qu'un esprit malin se joue de la mesure d'où cet épice qui vide le(s) cache(s)...

blockdev --flushbufs

Ainsi, j'ai pu agrémenter ma cuisine avec 3 séquences d'une même taille totale mais avec 3 blocs différents:

512 octets, 4096 octets et 1048576 octets,

dont je ne sais si le choix est judicieux mais il permet de comparer le débit selon que le bloc est petit ou grand (petit fichier ou grand fichier)

Code BASH :

dd if=/dev/sdb1 of=/dev/null bs=1b count=204800 skip=0
204800+0 enregistrements lus
204800+0 enregistrements écrits
104857600 octets (105 MB) copiés, 0,765898 s, 137 MB/s
blockdev --flushbufs /dev/sdb1
 dd if=/dev/sdb1 of=/dev/null bs=4k count=25600 skip=0
25600+0 enregistrements lus
25600+0 enregistrements écrits
104857600 octets (105 MB) copiés, 0,74305 s, 141 MB/s
blockdev --flushbufs /dev/sdb1
dd if=/dev/sdb1 of=/dev/null bs=1M count=100 skip=0
100+0 enregistrements lus
100+0 enregistrements écrits
104857600 octets (105 MB) copiés, 0,720027 s, 146 MB/s
blockdev --flushbufs /dev/sdb1

Mais dans ma recette, y avait quelquechose qui manquait, autant la taille bloc physique du DD m'était connue, autant celle du type de système de fichier ne m'était pas connue, le formattage à l'installation (drakdisk) étant muet là-dessus d'où un petit

blockdev --report

Code BASH :

blockdev --report
RO    RA   SSZ   BSZ  1er sect.          Taille   Périphérique
rw   256   512  4096          0     80026361856   /dev/sda
rw   256   512  4096         63     21467948544   /dev/sda1
rw   256   512  4096   41929650     42952412160   /dev/sda2
rw   256   512  4096  125821080     15603356160   /dev/sda3
rw   256   512  4096          0    500107862016   /dev/sdb
rw   256   512  4096         63      4301789184   /dev/sdb1
rw   256   512  4096    8401995     12839662080   /dev/sdb2
rw   256   512  4096   33479460     19378759680   /dev/sdb3
rw   256   512  1024   71328600            1024   /dev/sdb4
rw   256   512  4096   71328663    359707912704   /dev/sdb5
rw   256   512   512  773883243     81611195904   /dev/sdb6
rw   256   512  4096  933280173     22265800704   /dev/sdb7

dont le BSZ joue le rôle de cafteur...

Édité par kalagani Le 26/04/2014 à 18h30

PC1: HPxw9400 Mageia8 Xfce/Cinnamon (ex Plasma car "Freeze")
PC2: Dell Studio 540 Core2 Quad Q8300 en double boot: XPsp3/Mageia8 64bits Plasma

kalagani Membre non connecté

Le 26/04/2014 à 18h57

#174512

@nmrk.n, les ambulanciers ne m'ont pas trouvé...:+)

alors la suite:
dd en écriture:
même méthode que pour dd en lecture avec bs et count et les 3 séquences d'une même taille totale à 3 blocs différents de 512 octets, 4096 octets et 1048576 octets précédées d'un purge cache

Code BASH :

blockdev --flushbufs /dev/sdb3
dd if=/dev/zero of=/home/tmpFile bs=1b count=204800 skip=0
104857600 octets (105 MB) copiés, 1,2019 s, 87,2 MB/s
blockdev --flushbufs /dev/sdb3
dd if=/dev/zero of=/home/tmpFile bs=4k count=25600 skip=0
104857600 octets (105 MB) copiés, 0,423845 s, 247 MB/s
blockdev --flushbufs /dev/sdb3
dd if=/dev/zero of=/home/tmpFile bs=1M count=100 skip=0
104857600 octets (105 MB) copiés, 0,392104 s, 267 MB/s

et cette séquence sur chaque partition, qu'il faut évidemment monter avant si elle ne le sont pas toutes, (si double, triple ou x-boot par exemple...) via quelques lignes pour automatiser par exemple de nouveau

Code BASH :

disque=sda; for part in `fdisk -l /dev/$disque |egrep -vi 'disque|disk' |awk 'BEGIN{FS="/dev/"}{print $2}' |grep -v "^s*$" |awk '{print $1}'`
do
if !(cat /proc/mounts |grep /dev/$part)
  then mkdir /mnt/test$part 2> /dev/null
  mount /dev/$part /mnt/test$part
fi
path2w=`df |grep $part |awk '{print $6}'`
blockdev --flushbufs /dev/$part
dd if=/dev/zero of=$path2w/tmpFile$part bs=1b count=204800 skip=0
blockdev --flushbufs /dev/$part
dd if=/dev/zero of=$path2w/tmpFile$part bs=4k count=25600 skip=0
blockdev --flushbufs /dev/$part
dd if=/dev/zero of=$path2w/tmpFile$part bs=1M count=100 skip=0
done

Ah...j'entend une sirène...mais qui a appelé les pompiers?

Édité par kalagani Le 26/04/2014 à 19h40

PC1: HPxw9400 Mageia8 Xfce/Cinnamon (ex Plasma car "Freeze")
PC2: Dell Studio 540 Core2 Quad Q8300 en double boot: XPsp3/Mageia8 64bits Plasma

kalagani Membre non connecté

Le 27/04/2014 à 19h48

#174582

Hello,

@nmrk.n

Citation :

Est-ce que les partitions étendues d'un disque SSD doivent être alignées ?

Je dirai que SSD ou DD classique, même combat:

la partition étendue doit être alignée et à l'intérieur de celle-ci les partitions logiques doivent l'être également!

Citation :

Que penses-tu du fichier ci-dessous ?

Je l'ai sauvegardé, mais je n'arrive pas à faire un copier/coller du fdisk -lu /dev/sda d'un coup, me faut coller cellule par cellule!

Pour le contenu, y a t-il une raison à ce que tu aies ajouté 2030 en fin de sda3(=184322047)

pour arriver au début de ta sda4(=184324077)?

Pour moi, il faut juste continuer au secteur suivant soit +1en fin de sda3(=184322048)

et ensuite pour respecter l'alignement de la première partition logique ajouter les 2048 comme tu as fait!

/dev/sda4	184324077	245764095	30720009+	5	Étendue	90 002	2029	Non aligné !	120 002	2047	Non aligné !	15 000	9	Non aligné !
devient
/dev/sda4	184322048	245764095	203736328	5	Étendue	90 001	0	Ok	120 002	2047	Non aligné !	15 000	9	Non aligné !

Entre parenthèses si 245764095 est vraiment la fin de ton SSD, pourquoi ne pas oser 4 partitions primaires?

@Adrien.D

ni SSD, ni DD 4Kio, des DD tout ce qu'il y a de plus classique à secteur physique de 512octets

PC1: HPxw9400 Mageia8 Xfce/Cinnamon (ex Plasma car "Freeze")
PC2: Dell Studio 540 Core2 Quad Q8300 en double boot: XPsp3/Mageia8 64bits Plasma

kalagani Membre non connecté

Le 27/04/2014 à 23h11

#174599

Merci du lien MadTux,

ce qui est proposé me conforte dans ce que j'ai mis dans un script de test

Citation :

Using hdparm

# hdparm -Tt /dev/sdX

/dev/sdX:

Timing cached reads: x MB in y seconds = z MB/sec

Timing buffered disk reads: x MB in y seconds = z MB/sec

Note: One should run the above command 4-5 times and manually average the results for an accurate evaluation of read speed per the hddparm man page.

-> mis dans mon script, me faudrait rajouter le coup de le faire plusieurs fois, puis la moyenne...

Citation :

First, enter a directory on the SSD with at least 1.1 GB of free space (and one that obviously gives your user wrx permissions) and write a test file to measure write speeds and to give the device something to read:

$ cd /path/to/SSD

$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc

1024+0 records in

1024+0 records out

w bytes (x GB) copied, y s, z MB/s

-> je le fais partition par partition, inutile sur un SSD car même vitesse d'accès mais pas sur un DD où le débit est différent entre bord et centre de plateau...

par contre je ne mettais pas conv=fdatasync,notrunc, quelle utilité?

EDIT 10/05/2014:

fdatasync: indispensable pour éviter à Linux d'optimiser les écritures DD en faisant de la rétention en cache.

si absent, c'est flagrant avec écriture de zero, (débits supérieurs au débit théorique SATA), moins en écriture aléatoire urandom => rajouté dans script

notrunc: indispensable lorsqu'on veut ré-écrire sur un fichier existant sans pour autant tronquer celui-ci cf ici à mon avis inutile ici, le but n'étant pas de conserver l'intégrité de taille du fichier même quand il porte le même nom que lors de l'écriture précédente (cas de boucle à bs différents).

Citation :

Next, clear the buffer-cache to accurately measure read speeds directly from the device:

# echo 3 > /proc/sys/vm/drop_caches

-> je le fais avant chaque lecture ou écriture mais via blockdev --flushbufs /dev/sdxy sur chaque partition

je ne sais si c'est équivalent!

Citation :

$ dd if=tempfile of=/dev/null bs=1M count=1024

1024+0 records in

1024+0 records out

w bytes (x GB) copied, y s, z MB/s

-> je le fais partition par partition, là aussi inutile sur un SSD car même vitesse d'accès mais pas sur un DD où le débit est différent entre bord et centre de plateau...

Citation :

Now that the last file is in the buffer, repeat the command to see the speed of the buffer-cache:

$ dd if=tempfile of=/dev/null bs=1M count=1024

1024+0 records in

1024+0 records out

w bytes (x GB) copied, y s, z GB/s

-> ça je ne le fais pas car le but de mon script sera de comparer les résultats entre des alignements différents et donc d'éviter d'être trompé par le cache...

Édité par kalagani Le 10/05/2014 à 16h14

PC1: HPxw9400 Mageia8 Xfce/Cinnamon (ex Plasma car "Freeze")
PC2: Dell Studio 540 Core2 Quad Q8300 en double boot: XPsp3/Mageia8 64bits Plasma

kalagani Membre non connecté

Le 28/04/2014 à 20h21

#174643

Hello nmrk.n,

avec tes conseils j'ai réussi à importer les partitions...

bien sûr les calculs du fichier étant basés sur 2048 alors avec 2 DD commençant à 63 et le dernier à 1, le résultat est comme attendu: rien n'est aligné, c'est comme avec parted -align-check optimal

Citation :

Pour le contenu c'était le premier formatage aligné que je faisais et j'ai laissé comme a fait GParted. Je ne sais pas d'où viennent ces 2030, j'ai peut-être fait une mauvaise manœuvre.

Si tu as repris le résultat de Gparted pour mettre dans ton fichier, alors ce dernier ne te sert qu'à vérifier.

Pour moi, je verrai la démarche dans l'autre sens, le fichier servant d'abord à calculer alignement/taille, et ensuite à rentrer les valeurs dans Gparted (si c'est faisable) sinon en ligne de commande avec fdisk qui aligne automatiquement sur 2048 depuis plusieurs versions...

Je suis étonné que ce soit Gparted qui ait mal aligné la partition étendue, mais pourquoi pas, je peux me tromper en disant qu'elle doit être alignée, en fait l'étendue ne sert que de relais pour accéder à la 1ère logique qui elle doit être alignée puisqu'elle contient des données, alors que l'étendue n'a que le 1er secteur EBR qui sert, le reste (2030-1 ou 2048-1) étant perdu...

Citation :

Je souhaites d'abord savoir si ce fichier est correct et au cas ou ça intéresse quelqu'un ...

Qu'est-ce tu penses des autres colonnes, fins de partitions et blocs, est-ce que ça a un intérêt ?

Pour la colonne O la plus importante, cela évite de sortir la calculatrice, mais méfie toi, l'arrondi choisi est trompeur!

Ainsi pour la partition étendue le nombre de 2048 est entier=90002 alors qu'il devrait être avec une virgule 184324077/2048=90 001,9907227

Même pb sur la colonne R de calcul de fin de partition...

P me semble inutile et serait à remplacer par un calcul de la taille de la partition liée aux 2 valeurs rentrées en début et fin

à priori (fin-début)*512 à diviser par une série de 1024 selon le résultat en Kio, Mio, Gio...à afficher

Du coup seules ces 3 colonnes me paraissent utiles...

Citation :

Qu'est-ce que je peux faire pour "rattraper" ma partition étendue, comment m'y prendre sans perte de données ?

Ce n'est pas la fin de mon SSD.

Qu'y a t-il sur ton Linux de la première partition logique, un système ou des données?

Quelle est la taille de ton SSD?

Par curiosité n'ayant pas de SSD peux tu me coller le résultat d'un

hdparm -ItT /dev/sda

et d'un

blockdev --report /dev/sda?

Édité par kalagani Le 28/04/2014 à 20h35

PC1: HPxw9400 Mageia8 Xfce/Cinnamon (ex Plasma car "Freeze")
PC2: Dell Studio 540 Core2 Quad Q8300 en double boot: XPsp3/Mageia8 64bits Plasma

kalagani Membre non connecté

Le 28/04/2014 à 23h26

#174683

Bonsoir,

mrk.n :

Je me pose la question pour la partition étendue parce qu'elle n'est en fait qu'un "conteneur" et c'est aux partitions qui sont à "l'intérieur" qu'il faut en fait accéder.

c'est un peu ce que j'ai dit

kalagani :

en fait l'étendue ne sert que de relais pour accéder à la 1ère logique qui elle doit être alignée puisqu'elle contient des données, alors que l'étendue n'a que le 1er secteur EBR qui sert, le reste (2030-1 ou 2048-1) étant perdu...

que je complèterai en précisant que l'étendue n'est le conteneur dans son EBR que de 2 adresses de partitions:

_celle sur la 1ère partition logique

_celle de chainage sur le prochain EBR (s'il existe)

lequel second EBR contiendra lui aussi la même chose et ainsi de suite...jusqu'au max de 20 partitions logiques je crois!

Là que l'étendue ne soit pas alignée n'est pas gênante en terme de taille de donnée utiles à accéder, (l'EBR et ses 512 octets)

ce qui pourrait être pénalisant est le nombre d'accès, mais vu le peu de donnée à lire il est peu probable qu'il y ait 2 accès pour cela...L'important c'est que les partitions logiques soient elles alignées!

Citation :

Je ne pense pas que la colonne "O" soit la plus importante ou alors il faudrait afficher un nombre impressionnant de décimales, c'est la raison pour laquelle j'ai choisi volontairement de ne mettre aucune décimale en sachant que ce n'est pas sur cette colonne qu'il faut se baser, elle n'est qu'un ordre de grandeur.

C'est l'éternel problème entre ce qui est utile pour l'un ou pour l'autre.

Perso, 3 colonnes me suffiraient avec la "O" dont le résultat ne doit pas tolérer d'arrondi dans le calcul

puisque je persiste c'est elle qui détermine le début de la partition, s'il y a une virgule c'est que la partition n'est pas alignée.

Une seconde pour le calcul de la taille...La 3ème un modulo 2048 sur la fin partition pour être au plus près de 2047 histoire d'avoir le dernier accès le plus "plein" possible, sachant qu'il ne le sera jamais puisque la fin d'une partition ne peut être alignée sauf à perdre 1 secteur entre fin alignée et début alignée de la suivante...

Citation :

sda5 Mga3 29 Gio

un OS donc

puisque pas d'autre partition logique derrière, l'EBR de cet OS n'a pas de chainage

alors je tenterai (je ne l'ai jamais fait) une sauvegarde via dd

dd if=/dev/sda5 of=/point de montage d'un des DD/saveMageia3.img bs=4k

destruction de /dev/sda5 et /dev/sda4

reconstruction des 2 en alignant avec fdisk

restitution en se mettant sur le DD où est l'image

dd if=saveMageia3.img of=/dev/sda5 bs=4k

Note: faut être patient avec dd, c'est long de chez long...

EDIT 29/04/2014: pour la sauvegarde de cette sda5 il te faut aussi la place sur le DD qui doit la recevoir...

Mais avant de risquer la manip compare tes partition en lecture/écriture avec les commandes dd que j'ai mises plus haut

Comparaison de ton SSD

Citation :

Code BASH :

Timing cached reads: 1626 MB in 2.00 seconds = 813.48 MB/sec
Timing buffered disk reads: 634 MB in 3.00 seconds = 211.03 MB/sec

avec 1 de mes DD

Code BASH :

Timing cached reads:   2084 MB in  2.00 seconds = 1041.59 MB/sec
Timing buffered disk reads: 400 MB in  3.01 seconds = 132.91 MB/sec

accès direct meilleur sur le SSD mais étrange pas quand le cache est en jeu!!!

Même chose pour les RA SSZ BSZ, ton SSD

Citation :

Code BASH :

blockdev --report /dev/sda?
RO RA SSZ BSZ 1er sect. Taille Périphérique
rw 256 512 4096 2048 31457280000 /dev/sda1
rw 256 512 4096 61442048 31457280000 /dev/sda2
rw 256 512 4096 122882048 31457280000 /dev/sda3
rw 256 512 1024 184324077 1024 /dev/sda4
rw 256 512 4096 184324096 31457280000 /dev/sda5

mon même DD

Code BASH :

blockdev --report /dev/sdb?
RO    RA   SSZ   BSZ  1er sect.          Taille   Périphérique
rw   256   512  4096         63      4301789184   /dev/sdb1
rw   256   512  4096    8401995     12839662080   /dev/sdb2
rw   256   512  4096   33479460     19378759680   /dev/sdb3
rw   256   512  1024   71328600            1024   /dev/sdb4
rw   256   512  4096   71328663    359707912704   /dev/sdb5
rw   256   512   512  773883243     81611195904   /dev/sdb6
rw   256   512  4096  933280173     22265800704   /dev/sdb7

_RA (Read-Ahead) buffer en avance de phase pour améliorer la vitesse de lecture si j'ai bien compris

identique à la valeur par défaut de 256 secteurs

_SSZ size bloc logique identique aussi...en octets

c'est sur ces 2 paramètres que je pensais trouver une différence

_BSZ c'est la taille en octets du bloc du système de fichier utilisé sur la partition

4kio pour NTFS, ext4; 512 pour FAT chez moi

à noter le cas particulier de l'étendue dont le bloc et la taille ne font que 1024 octets/secteurs...

Édité par kalagani Le 29/04/2014 à 10h34

PC1: HPxw9400 Mageia8 Xfce/Cinnamon (ex Plasma car "Freeze")
PC2: Dell Studio 540 Core2 Quad Q8300 en double boot: XPsp3/Mageia8 64bits Plasma

Répondre

Vous n'êtes pas autorisé à écrire dans cette catégorie

Notre Mission	Liens du site	Nous joindre	MLO est hébergé par
MLO est le forum francophone de la distribution Mageia et vous propose également un portail dédié aux débutants. MLO vous apporte un support sur la distribution grâce à son forum et vous offre des nouvelles de la distribution, des logiciels libres et de l'Open Source en général. Notre site a aussi pour but de vous montrer que Mageia est un système d'exploitation complet et facile à prendre en main. Vous apprendrez à installer simplement et à administrer efficacement votre système en un temps record.	Forum Documentation News du libre Mageia	Contacter MLO Mastodon MLO Flux RSS	MLO est un projet soutenu par Nos partenaires et amis
MLO est mis à disposition selon les termes de la licence Creative Commons.

kalagani Membre non connecté

kalagani Membre non connecté

kalagani Membre non connecté

kalagani Membre non connecté

kalagani Membre non connecté

Adrien.D Membre non connecté

kalagani Membre non connecté

Adrien.D Membre non connecté

kalagani Membre non connecté

Visiteur

Adrien.D Membre non connecté

kalagani Membre non connecté

kalagani Membre non connecté

kalagani Membre non connecté

kalagani Membre non connecté