Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connections
Warning: mysqli::query(): Couldn't fetch mysqli in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\index.php on line 66
Article <NEBvIcHQWPUBLtWLr5quH9vziSE@jntp>
Deutsch   English   Français   Italiano  
<NEBvIcHQWPUBLtWLr5quH9vziSE@jntp>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.mixmin.net!weretis.net!feeder8.news.weretis.net!usenet.pasdenom.info!from-devjntp
Message-ID: <NEBvIcHQWPUBLtWLr5quH9vziSE@jntp>
JNTP-Route: news2.nemoweb.net
JNTP-DataType: Article
Subject: Re: lenteur disque =?UTF-8?Q?=28=C3=A0=20confirmer=29?=
References: <20211205191220.1c8dd5f5@coffee.novazur.fr> <sokdkb$beq$1@shakotay.alphanet.ch> <ZE2p2alY3bBvEkiRCC1BsuHUTN4@jntp>
 <solj0i$7rj$1@shakotay.alphanet.ch>
Newsgroups: fr.comp.os.linux.configuration
JNTP-HashClient: ONQL0MkUPuZ-BlYJyKHLqL-w-x8
JNTP-ThreadID: 20211205191220.1c8dd5f5@coffee.novazur.fr
JNTP-Uri: http://news2.nemoweb.net/?DataID=NEBvIcHQWPUBLtWLr5quH9vziSE@jntp
User-Agent: Nemo/0.999a
JNTP-OriginServer: news2.nemoweb.net
Date: Mon, 06 Dec 21 18:09:44 +0000
Organization: Nemoweb
JNTP-Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Injection-Info: news2.nemoweb.net; posting-host="57a7697b711e1390e43e8d98aa87a8bb5a5fec17"; logging-data="2021-12-06T18:09:44Z/6347693"; posting-account="44@news2.nemoweb.net"; mail-complaints-to="newsmaster@news2.nemoweb.net"
JNTP-ProtocolVersion: 0.21.1
JNTP-Server: PhpNemoServer/0.94.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-JNTP-JsonNewsGateway: 0.96
From: pehache <pehache.7@gmail.com>
Bytes: 3397
Lines: 37

Le 06/12/2021 à 18:58, Marc SCHAEFER a écrit :
> pehache <pehache.7@gmail.com> wrote:
>>> Sur les disques SSD, j'ai trop peu d'expérience. Il faut savoir que par
>>> parano j'ai jusqu'ici systématiquement laissé un bon bout non
>>> partitionné en me disant que cela leur servirait de blocs de
>>> remplacement, 
>> 
>> Autant que je sache la réserve de blocs n'est pas sur le volume 
>> accessible par l'OS, et même si tu ne partitionnes pas tout, les blocs 
>> libres ne seront pas utilisés pour remplacer les blocs défectueux.
> 
> Effectivement, le SSD n'a aucun moyen de savoir qu'ils ne sont pas
> alloués. Par contre, il a moyen de voir qu'ils n'ont jamais été
> utilisés.
> 
> Typiquement, le fait que la commande `trim' existe me faisait penser
> qu'il pouvait avoir -- en plus d'un pré-effacement -- utilisation des
> blocs non alloués comme blocs de réallocation.
> 
> Je me disais qu'il pouvait éventuellement noter quels blocs logiques
> sont mappés où, et mapper au fur et à mesure. Mais c'est plus complexe
> qu'une simple table de réallocation avec des blocs réservés pour.

Il pourrait faire ça, oui, mais il y aurait un "petit" souci si ensuite 
tu voulais récupérer l'espace initialement non partionné. D'où le fait 
que la réserve de blocs vient "en plus" de l'espace visible par l'OS.

> 
> Je cite Wikipedia: "Cette technique permet en outre d'augmenter la durée
> de vie des SSD, par la mise en rotation des cellules utilisées à chaque
> écriture - à la condition de laisser suffisamment d'espace libre sur le
> support. En effet, plus l'espace de stockage disponible est restreint,
> plus les écritures se feront fréquemment sur les mêmes cellules,
> réduisant donc l'efficacité de cette technique. "

Oui, mais ça c'est dans le but de permettre au garbage collector de mieux 
fonctionner (si tant est qu'il y ait besoin qu'il fonctionne mieux).