He mirat amb Debian 6, 7, 8 i Ubuntu 14.04 i totes coincideixen en
aquests valors predeterminats de sysctl:
# Tiempo mínimo antes de escribir en disco los datos de cache:
vm.dirty_expire_centisecs = 3000
# Intervalo de comprobación de cache para escribir expirados en disco:
Josep Lladonosa:
> Una situació dins l'etc. amb què m'he trobat sovint és algun procés del
> sistema de fitxers ext4 i el journaling, on un procés en rerefons va fent
> fins que ho té tot actualitzat. On se m'ha constatat més ha estat durant la
> utilització de discos usb.
Els discs flash,
2016-06-09 15:59 GMT+02:00 Narcis Garcia :
> Apart de l'updatedb hi ha l'equivalent «tracker» de Gnome, que no entenc
> com no té en compte que l'usuari està treballant (ho podria detectar amb
> el salvapantalles).
>
> Bé, sobre detalls com aquest a l'hora de configurar
Apart de l'updatedb hi ha l'equivalent «tracker» de Gnome, que no entenc
com no té en compte que l'usuari està treballant (ho podria detectar amb
el salvapantalles).
Bé, sobre detalls com aquest a l'hora de configurar ordinadors, sovint
dedico molt més esforç a una aparent «tonteria» perquè quan
Narcis Garcia:
> Alguns ordinadors els he vist treballar molt sobre disc dur
> quan l'usuari (ni cap servei previst) no està fent res i
> podria tenir a veure amb això (?).
Hi ha processos del cron que s'executen periòdicament i que
poden un ús de disc força intensiu, segons les dades que hagin
En els discs, en volum de dades, és lògic que la lectura aleatòria és
més lenta que la seqüencial.
Jo també havia sentit això de la desfragmentació automàtica, suposo que
es produïria de mica en mica per a què no calgui esperar. Alguns
ordinadors els he vist treballar molt sobre disc dur quan
Sigui com sigui, i encara que digui «no problem», m'agradaria saber el
perquè del «Failure 5/318» d'aquest petit exemple:
$ e4defrag /boot
[2/318]/boot/initrd.img-3.16.0-4-amd64: 100%[ OK ]
(...)
[317/318]/boot/grub/fonts/unicode.pf2: 100%[ OK ]
[318/318]/boot/grub/unicode.pf2:
A 2016-06-08 16:27, Narcis Garcia escrigué:
He provat aquesta eina de e2fsprogs defragmentant particions de
diversos
ordinadors (Debian 7, Debian 8, Ubuntu 14, arrel, /home separat o no,
/boot separat o no, etc.) I al final conclou amb un recompte de fitxers
defragmentats existosament i dels
Narcis Garcia:
> A alguns ordinadors antics els reviso *molts* detalls per aconseguir una
> engruna més de velocitat, que en aquest cas té a veure amb l'arrencada i
> amb la càrrega d'aplicacions.
Has pogut comprovar empíricament alguna millora de rendiment amb
la desfragmentació? El rendiment
2016-06- 8, 19:32 (+0200); Josep Lladonosa escriu:
> Necessites realment desfragmentar? Pel que diuen, no cal, si tens la
> partició a menys del 80-95% d'ocupació.
Que jo sàpiga ext2/3/4 no necessita desfragmentar. Sense haver
desfragmentat mai aquest disc, ho acabo de mirar i només troba 2
Si, la forma «manual» de desfragmentar (còpia, formatat i restauració)
ja la utilitzava abans de trobar el e4defrag, però no té els avantatges
que el e4defrag com per exemple poder disposar de l'ordinador
immediatament o fer-ho per control remot.
A alguns ordinadors antics els reviso *molts*
On 8 Jun 2016 16:45, "Narcis Garcia" wrote:
>
> He provat aquesta eina de e2fsprogs defragmentant particions de diversos
> ordinadors (Debian 7, Debian 8, Ubuntu 14, arrel, /home separat o no,
> /boot separat o no, etc.) I al final conclou amb un recompte de fitxers
>
He provat aquesta eina de e2fsprogs defragmentant particions de diversos
ordinadors (Debian 7, Debian 8, Ubuntu 14, arrel, /home separat o no,
/boot separat o no, etc.) I al final conclou amb un recompte de fitxers
defragmentats existosament i dels que no.
Els que no (Failure) sempre són una bona
13 matches
Mail list logo