Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Partitionnement disque SATA: 182Go au lieu de 200

6 réponses
Avatar
Julien Valroff
Bonjour,

Je viens d'installer Etch sur un nouveau disque SATA de 200Go, et le
système n'en reconnait que 182.

J'ai fait un partitionnement simple:
/ sur /dev/sda1 (20Go)
swap sur /dev/sda5 (2.8Go)
/home sur /dev/sda6 (le reste soit environ 177,2Go)

julien@hathor:~$ df -h
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/sda1 19G 1,2G 17G 7% /
tmpfs 506M 0 506M 0% /dev/shm
/dev/sda6 163G 36M 155G 1% /home

Lors de l'étape de partitionnement à l'installation, partman m'indique
bien 200Go.
cfdisk me donne également les bonnes valeurs après l'installation du
système.

Voici la table des partitions affichée par cfdisk :
Partition Table for /dev/sda

---Starting--- ----Ending---- Start Number of
# Flags Head Sect Cyl ID Head Sect Cyl Sector Sectors
-- ----- ---- ---- ---- ---- ---- ---- ---- ----------- -----------
1 0x80 1 1 0 0x83 254 63 1023 63 39070017
2 0x00 254 63 1023 0x05 254 63 1023 39070080 351646785
3 0x00 0 0 0 0x00 0 0 0 0 0
4 0x00 0 0 0 0x00 0 0 0 0 0
5 0x00 254 63 1023 0x82 254 63 1023 63 5462037
6 0x00 254 63 1023 0x83 254 63 1023 63 346184622


Je n'ai jamais eu de disques d'aussi grosse capacité, ni de SATA, du
coup, je en sais pas à quoi c'est dû : limitation du SATA, trop grosse
partition ou autre.

J'ai un noyau standard 2.6.8-2-686-smp (je n'ai pas encore recompilé).

Je ne sais pas trop où orienter mes recherches, si quelqu'un a une idée,
elle est la bienvenue ;-)

@++
Julien



--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

6 réponses

Avatar
Jean-Luc Coulon (f5ibh)
--=-KPCVdErEEQjfALG5BFJK
Content-Type: text/plain; charset=iso-8859-1; DelSp=Yes; Format=Flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Le 16.10.2005 14:13:10, Julien Valroff a écrit :
Bonjour,



....

:~$ df -h
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/sda1 19G 1,2G 17G 7% /
tmpfs 506M 0 506M 0% /dev/shm
/dev/sda6 163G 36M 155G 1% /home





Taille : 163G, Occupé : 36M, Disponible = 155G
163-36 = 127 ... ????


J-L

--=-KPCVdErEEQjfALG5BFJK
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBDUkpxXit3lz9m7V4RAhNHAJ0YDlvBysWA8HGg/5zO1+0YuuIJPACfZ1B/
0++cOMhfi2VHP8BFWrRecZI =kxpb
-----END PGP SIGNATURE-----

--=-KPCVdErEEQjfALG5BFJK--


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Philippe
Le dimanche 16 octobre 2005 à 15:28 +0200, Sebastien a écrit :
Bonjour,

>



df, partman et cfdisk ont tous raison mais dans leur unité et en prenant en compte l'espace réservé pour le superutilisateur !




Oui tu as raison et j'ai fait un raccourci erroné, les unités de df sont
correctement explicité dans le man. c'est donc le mail de départ qui est
faux car il compare des Gio et des Go
comme quoi faut toujours verifier les unités

>
> pour la163 - 36 <> 155 essaye de faire un du -sh /home
on ne soustrait pas des Mo à des Go ! différence dans les unités et du aux 5% réservés ! ;-)



oups
effectivement c'est pas les mêmes prefixe au temps pour moi.

163 - 163 *5% ~ 155

> Si tu as manipuler des gros fichiers recement il est probable que du et
> df donne des resultats tres differents.
jamais remarqué de différence !



si tu effaces un gros fichier qui est ouvert il occupe de la place (vu
par df) mais il n'est pas trouvé par du


Sébastien





--
Philippe


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
philippe dunski
Salut,


Là tu te trompes. C'est précisément le contraire. La norme
internationale (SI) est la base 10. Seul un certain milieu
informatique utilise la base 2. Même les milieux des réseaux et des
télécoms utilisent la base 10 (gigabit ethernet = 10^9 bit/s).



Personnellement, j'aurais plutot tendance à estimer que c'est à tord que
l'industrie des disque durs compte avec des unités allant par 1000 et
non par 1024...

Il faut bien se rendre compte du fait que TOUT dans un ordinateur insite
à utiliser une base réductible en binaire..

En effet, 1024 et ses multiples (je devrais presque plutot dire et "ses
exponancielles" vu que c'est bien de cela qu'il s'agit) sont des valeurs
représentables grace à un seul bit (pour autant qu'il y en ai un nombre
suffisant à "0" du bon coté), alors que AUCUN multiple de 1000 (ou de
ses exponantielles) n'est dans le cas (toutes les valeurs utilisables en
binaires et représentables avec un seul bit non nul terminent
inlassablement avec les valeurs d'unité 2, 4,8, 6, 2 revenant en boucle)

Il ne faut pas oublier non plus que la plus petite unité de stockage
disponible (que ce soit sur un disque dur ou une disquette ou ...) est
de ...512octets, et non 500...

Quel que soit le nombre de bits considéré pour l'adressage (car,
finalement, il n'y a aucune différence réelle entre l'adressage d'un
espace de stockage "disque dur" et celui d'un espace de stockage
"mémoire", du point de vue de l'adressage, tout du moins), en utilisant
un seul bit non nul; il n'y a rien à faire, nous obtiendrons
systématiquement des valeurs multiples de 1024 (ou 512, si vraiment on
ne considère qu'un seul bit)

Le calcul sur base de 1024 est donc logiquement utilisé parce qu'il
permet la représentation logique d'une situation de fait qui rend toute
autre tentative de se raccrocher à d'autres standard aberrante...

En suivant la logique que tu sous entend presque, on pourrait comprendre
le fait qu'il y ai 365 jour 1/4 par an (du fait que c'est le temps réel
mis par la terre pour faire un tour complet autour du soleil), mais il
deviendrait presque illogique d'avoir 24heures par jours, 60 minutes par
heure, et 60 secondes par minute, ce qui, soit dit en passant, est bien
plus éloigné de la "norme" qui veut qu'on compte par dix que celle de
compter jusque 1024 au lieu de 1000...

De la meme manière, il deviendrait presque illogique de considérer qu'un
tour complet fasse 360°...

Finalement, les normes de calcul n'ont réellement un sens qu'à partir du
moment où elles permettent de représenter logiquement et fidèlement un
état donné dans un domaine donné, quel que puisse être cet état...

Et, si tu as suivi mes explications, tu conviendra sans doute avec moi
que le fait de calculer sur base de 1024 en informatique est la
représentation fidèle la plus logique des deux...


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Sylvain Sauvage
Mercredi 19 octobre 2005, 00:42:33 CEST, philippe dunski a écrit :

Salut,



'lut,

Personnellement, j'aurais plutot tendance à estimer que c'est à tord que
l'industrie des disque durs compte avec des unités allant par 1000 et
non par 1024...
[...]
Il ne faut pas oublier non plus que la plus petite unité de stockage
disponible (que ce soit sur un disque dur ou une disquette ou ...) est
de ...512octets, et non 500...
[...]
Finalement, les normes de calcul n'ont réellement un sens qu'à partir du
moment où elles permettent de représenter logiquement et fidèlement un
état donné dans un domaine donné, quel que puisse être cet état ...

Et, si tu as suivi mes explications, tu conviendra sans doute avec moi
que le fait de calculer sur base de 1024 en informatique est la
représentation fidèle la plus logique des deux...



Le système international des unités demande d'utiliser le système
décimal. Les multiplicateurs k, M, G, T... sont donc _déjà prises_ pa r le
SI (pour les puissances ternaires de 10 : 10^3, 10^6..., ou 10^-3,
10^-6... mais il y a aussi des multiplicateurs pour les premières
puissances de 10 : da, h, d, c).

Par _abus_, ces unités ont été utilisées pour les puissances _d écimales_
de deux (2^10, 2^20...) car elles se _rapprochent_ des puissances
ternaires de 10.

L'industrie des supports a _toujours_ utilisé les unités du SI d'une
façon bâtarde :
- d'un côté, 1 Mo = 1000 ko, 1 Go = 1000 Mo, etc., ce qui est corre ct vis
à vis du SI ;
- de l'autre, 1 ko = 2 secteurs de 512 octets.

En fait, on peut considérer que les 2,4 % de différence sont un cadeau
de la part du producteur. En tout cas, ce n'est pas dans le but de flouer
le client : il n'y a que depuis peu de temps que le vulgus pecum achète
des supports. Les producteurs sont des ingénieurs, ils utilisent le SI.
De plus, l'usage de la base deux comme « base logique du domaine »
comme tu pourrais la qualifier se défend pour les données qui seront
mises sur le support mais cet usage ne se défend absolument pas pour
quantifier l'espace des supports. Les supports sont _matériels._
Imagine-toi par exemple qu'un disque dur peut comporter trois plateaux ou
cinq ou dix. Autre exemple, une disquette 90 mm contient 1440*1024
octets. Alors, va-t-on forcer l'industrie à construire ses supports en
binaire ?

On notera aussi que les industriels ont toujours 2,4 % d'écart par
rapport au nombre total d'octets alors que ceux qui utilisent les
multiplicateurs du SI mal à propos augmentent l'écart de jour en jour :
quand les disques sont en Mo, il y a 4,8 %, en Go, 7,4 %, en To,
10,0 %, etc.

Toujours est-il qu'il existe maintenant une distinction entre les vrais
multiplicateurs du SI et les multiplicateurs binaires : les seconds sont
ki (kibi), Mi (Mebi), Gi (Gibi)¹...

¹ : pas de Shadock !

Cette proposition date de 1996, a été adoptée par l'ANSI en 1999 et
permet de clarifier la situation sans nécessiter de trop gros efforts.
(Il y a eu d'autres propositions mais je ne connais que celle-là qui ait
fait l'objet d'une adoption par un organisme de standardisation au moins
national.)

Alors tu peux vitupérer à tout va, mais crois-tu qu'il soit plus sens é
de soutenir un usage erroné et créateur de confusions ou d'utiliser un
système clair ?

Je pense qu'il est clair que l'utilisation des nouveaux multiplicateurs
est de mise.
Donc, que ceux pour qui cela a un intérêt premier, c'est-à-dire les
informaticiens et les utilisateurs de l'outil informatique, commencent à
balayer devant leur porte et utilisent les bonnes unités.
On verra après comment « forcer » les industriels à donner la cap acité
des DD de la même façon pour que le consommateur s'y retrouve. Et, en
attendant, on répondra gentiment aux néophytes...

--
Sylvain Sauvage
Avatar
Pascal
Sylvain Sauvage a écrit :
[...]

Excellente analyse que je partage. Quelques observations toutefois.

L'industrie des supports a _toujours_ utilisé les unités du SI d'une
façon bâtarde :
- d'un côté, 1 Mo = 1000 ko, 1 Go = 1000 Mo, etc., ce qui est correct vis
à vis du SI ;
- de l'autre, 1 ko = 2 secteurs de 512 octets.



Mais sans le dire, et pas toujours. J'ai bien un disque Hitachi
estampillé "160 Go" qui fait 164 Go et des poussières, mais aussi un
Maxtor "20 Go" qui fait exactement 20 Go à l'octet près.

Mais l'exception la plus notable de la part de l'industrie concerne les
CD : un CD de 74 mn est estampillé "650 Mo" alors qu'il s'agit de 650
Mio, soit ~680 Mo. Mais l'industrie du support optique est rentrée dans
le rang avec le DVD pour lequel les 4,7 Go annoncés sont bien 4,7 Go.

En tout cas, ce n'est pas dans le but de flouer
le client : il n'y a que depuis peu de temps que le vulgus pecum achète
des supports. Les producteurs sont des ingénieurs, ils utilisent le SI.



Et le vulgus pecum simple utilisateur, il n'en a un peu rien à cirer que
dedans il y ait du binaire. Les fichiers ont des tailles quelconques, et
les supports actuels ont des tailles tellement élevées que le petit
facteur 512 (supports magnétiques) ou 2048 (supports optiques) y est
complètement noyé et invisible. Par contre l'utilisateur, il n'a
peut-être pas envie de se faire chier quand il doit combiner mentalement
des méga-octets et des kilo-octets. Et avec les préfixes binaires, c'est
pas gagné.


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Sylvain Sauvage
Mercredi 19 octobre 2005, 08:50:58 CEST, a écrit :
[...]
Mais sans le dire, et pas toujours. J'ai bien un disque Hitachi
estampillé "160 Go" qui fait 164 Go et des poussières, mais aussi un
Maxtor "20 Go" qui fait exactement 20 Go à l'octet près.



Il y a une petite couche marketing quand même : c'est plus simple de
vendre un 160 Go qu'un 159 Go, surtout quand les concurrents vendent
aussi un 160 Go mais qui fait 164,2 Go parce qu'il n'a pas le même nombre
de plateaux ou autre. Une histoire de nombres dits « ronds »¹.

¹ : Quand on vous dit « nombre rond » et que vous commencez à pense r à 2,
4, 8, ..., 1024, etc., c'est que vous devriez sortir plus souvent...

Mais l'exception la plus notable de la part de l'industrie concerne les
CD : un CD de 74 mn est estampillé "650 Mo" alors qu'il s'agit de 650
Mio, soit ~680 Mo. Mais l'industrie du support optique est rentrée dans
le rang avec le DVD pour lequel les 4,7 Go annoncés sont bien 4,7 Go.



C'est vrai, j'avais oublié les supports optiques. Je n'avais pas eu à
graver de DVD jusqu'à récemment et, quand je l'ai fait, j'ai passé un
moment à vérifier si c'était 4,7 Gio ou 4,7 Go (300 Mio de différen ce
ça devient important).

--
Sylvain Sauvage