Re: (deb-cat) Desfragmentacio de l'arrencada
On Thu, 25 Feb 2021 at 10:46, Àlex wrote: > > > On Wed, Feb 24, 2021 at 08:47:26AM +0100, Narcis Garcia wrote: > > > > Però l'arrencada carrega per exemple el gestor d'arrencada (A) el qual > > carrega el sistema del nucli (B), i el qual aleshores demana fitxers > > d'arreu com R, J, Y, D, K per la qual cosa el capçal d'un disc dur no fa > > més que canviar de posició tota l'estona i fent que la càrrega sigui > > molt més lenta del què el disc seria capaç de transmetre seqüencialment. > > Això es nota molt amb el soroll d'un disc dur quan arrenca el sistema. > > > Jo no veig clar que s'estalvii res per col.locar els fitxers > sequencialment al disc dur: > > A SDD ja es veu clarament que no hi ha cap estalvi per que no funcionen > així. > > A HDD tot i que els fitxers es llegeixen en un ordre, hi ha un espai de > temps entre fitxer i fitxer. No és que llegeixi el fitxer A i tal com acabo > llegeixo el fitxer B, sino que llegeixo el fitxer A, processo el fitxer A > mentre el disc dur gira, i quan acabo de fer el que em calgui llegeixo el > fitxer B, crec jo. > Cada fabricant té la seva electrònica i lògica en el disc. Per superar aquest entrebanc que comentes (esperar), una bona arquitectura (que no sabem si és així, però) tindria un doble búffer de lectura i doble processador de manera que mentre es processa allò llegit, es pot estar llegint el que toca després. M'has fet calcular quin seria el temps de rotació en un disc dur. A la mateixa velocitat tots els cilindres triguen el mateix en girar. Si el disc és de 5400 rpm, una volta sencera triga 11,11 ms, així que hi ha prou temps per "processar". En cas d'un disc sense aquest doble búffer, aquest seria el temps que trigaria, per exemple, en començar a llegir el fitxer B després de l'A. Tot consultant la Viquipèdia [1] he vist que aquest temps del que s'està parlant és la "latència rotacional". Bé, els meus cinc cèntims en això. [1]: https://en.wikipedia.org/wiki/Hard_disk_drive_performance_characteristics > > Només he "percebut" estalvi de temps amb desfragmentació quan carregaba el > sistema operatiu des de discos flexibles de 5 1/4 que amb el temps us > s'havien fragmentat molt. Mai més he "percebut" aquest estalvi de temps > defragmentant un hdd. > > salutacions > > > -- > La solidaritat és la tendresa dels pobles. Lluita contra l'apartheid: > > https://www.btselem.org/publications/fulltext/202101_this_is_apartheid > > https://www.elsaltodiario.com/ocupacion-israeli/apartheid-sanitario-israeli-metafora-kibbutz > > -- -- Salutacions...Josep --
Re: (deb-cat) Desfragmentacio de l'arrencada
> On Wed, Feb 24, 2021 at 08:47:26AM +0100, Narcis Garcia wrote: > > Però l'arrencada carrega per exemple el gestor d'arrencada (A) el qual > carrega el sistema del nucli (B), i el qual aleshores demana fitxers > d'arreu com R, J, Y, D, K per la qual cosa el capçal d'un disc dur no fa > més que canviar de posició tota l'estona i fent que la càrrega sigui > molt més lenta del què el disc seria capaç de transmetre seqüencialment. > Això es nota molt amb el soroll d'un disc dur quan arrenca el sistema. Jo no veig clar que s'estalvii res per col.locar els fitxers sequencialment al disc dur: A SDD ja es veu clarament que no hi ha cap estalvi per que no funcionen així. A HDD tot i que els fitxers es llegeixen en un ordre, hi ha un espai de temps entre fitxer i fitxer. No és que llegeixi el fitxer A i tal com acabo llegeixo el fitxer B, sino que llegeixo el fitxer A, processo el fitxer A mentre el disc dur gira, i quan acabo de fer el que em calgui llegeixo el fitxer B, crec jo. Només he "percebut" estalvi de temps amb desfragmentació quan carregaba el sistema operatiu des de discos flexibles de 5 1/4 que amb el temps us s'havien fragmentat molt. Mai més he "percebut" aquest estalvi de temps defragmentant un hdd. salutacions -- La solidaritat és la tendresa dels pobles. Lluita contra l'apartheid: https://www.btselem.org/publications/fulltext/202101_this_is_apartheid https://www.elsaltodiario.com/ocupacion-israeli/apartheid-sanitario-israeli-metafora-kibbutz
Re: (deb-cat) Desfragmentacio de l'arrencada
2021-02-24, 11:16 (+0100); Jordi Miguel escriu: > Si ho proves ja ens comentes l'experiència, i si la feina de muntar > aquestes coses val la pena per estalviar-se comprar un SSD per un > sistema antic. Amb el preu d'un SSD avui dia sembla difícil de > justificar el temps per configurar i mantenir aquestes artesanies, > però sempre és divertit pels amants de la tecnologia. Exacte... jo també tinc curiositat per saber en quin % es redueix el temps d'arrencada, amb aquest sistema, però m'imagino que deu ser un % molt baix. I per altra banda em pregunto si té sentit fer totes aquestes optimitzacions i després no recompilar el nucli i tots els paquets del sistema amb codi màquina optimitzat. Salutacions.
Re: (deb-cat) Desfragmentacio de l'arrencada
Hola, Aquestes eines que comentes va ser el primer q vaig pensar en llegir el correu del Narcís, pero després em vaig adonar que ell no estava pensant en el cas generic de que tots els trossets d'un fitxer estiguin guardats d manera consecutiva en el disc, sinó, que a banda de que els fitxers no estiguin fragmentats, un conjunt de fitxers (els q es llegiran al arrencar) estiguin emmagatzemats de forma consecutiva. Fins on tinc entès, les eines de defragmentació de disc generals no intenten optimitzar aquest cas i això es el que fa el e4rat-lite. Segurament seria convenient facilitar la feina del e4rat-lite començant amb un disc que no tingui fragmentació, amb lo qual el combo e4defrag + e4rat-lite seria interessant de provar. Fins aviat, Jordi El mié., 24 feb. 2021 18:54, Alex Muntada escribió: > Hola Jordi > > > Almenys existeix una eina que fa el que està buscant el Narcís, > > es diu e4rat i pots trobar informació al wiki de ArchLinux. > > Tanmateix l'eina original va quedar una mica "abandonada" i > > el projecte més actiu és un fork que es diu e4rat-lite > > Sembla que les versions recents dels nuclis linux duen activada > l'opció extend de l'ext4, que permet defragmentar a nivell de > fitxers amb e4defrag (ja ve amb el paquet e2fsprogs). > > Habitualment es deia que els sistemes de fitxers ext3 i ext4 > no es fragmentaven, però sembla que algú va fer una recerca més > detallada del tema i d'aquí en va sorgir l'eina e4defrag: > > > https://www.hecticgeek.com/defragment-ext4-file-systems-using-e4defrag-ubuntu/ > > Salut, > Alex > > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada > ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org > ⠈⠳⣄ > >
Re: (deb-cat) Desfragmentacio de l'arrencada
Hola Jordi > Almenys existeix una eina que fa el que està buscant el Narcís, > es diu e4rat i pots trobar informació al wiki de ArchLinux. > Tanmateix l'eina original va quedar una mica "abandonada" i > el projecte més actiu és un fork que es diu e4rat-lite Sembla que les versions recents dels nuclis linux duen activada l'opció extend de l'ext4, que permet defragmentar a nivell de fitxers amb e4defrag (ja ve amb el paquet e2fsprogs). Habitualment es deia que els sistemes de fitxers ext3 i ext4 no es fragmentaven, però sembla que algú va fer una recerca més detallada del tema i d'aquí en va sorgir l'eina e4defrag: https://www.hecticgeek.com/defragment-ext4-file-systems-using-e4defrag-ubuntu/ Salut, Alex -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org ⠈⠳⣄ signature.asc Description: PGP signature
Re: (deb-cat) Desfragmentacio de l'arrencada
__ I'm using this dedicated address because personal addresses aren't masked enough at this mail public archive. Public archive administrator should fix this against automated addresses collectors. El 24/2/21 a les 11:16, Jordi Miguel ha escrit: > El mié, 24 feb 2021 a las 10:58, Josep Lladonosa > () escribió: >> >> >> >> On Wed, 24 Feb 2021 at 08:47, Narcis Garcia wrote: >>> >>> Quan un ordinador arrenca, executa programes i aquests carreguen >>> llibreries i fitxers d'arreu del volum de disc. >>> Això produeix lectures aleatòries de centenars de fitxers amb els blocs >>> dispersos per tota la unitat ja que, quan es desfragmenta un disc dur, >>> la única cosa que s'ordena és que cada fitxer tingui els seus blocs de >>> dades contínus en el disc. >>> >>> És a dir, podem tenir fitxers emmagatzemats com a lletres: >>> A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z >>> >>> Però l'arrencada carrega per exemple el gestor d'arrencada (A) el qual >>> carrega el sistema del nucli (B), i el qual aleshores demana fitxers >>> d'arreu com R, J, Y, D, K per la qual cosa el capçal d'un disc dur no fa >>> més que canviar de posició tota l'estona i fent que la càrrega sigui >>> molt més lenta del què el disc seria capaç de transmetre seqüencialment. >>> Això es nota molt amb el soroll d'un disc dur quan arrenca el sistema. >>> >>> L'ideal en aquest exemple seria poder reorganitzar els blocs del disc així: >>> A,B,R,J,Y,D,K, C,E,F,G,H,I,L,M,N,O,P,Q,S,T,U,V,W,X,Z >>> De manera que de la A a la K es llegís tot sense interrupció. >>> >>> Hi ha alguna eina que faciliti això per accelerar l'arrencada? >> >> >> La meva proposta passa per afegir maquinari (un ssd on el temps de >> "posicionament" és molt petit i més o menys constant). >> Podríeu teniri un ssd "petitó" utilitzat en forma de memòria cau (estil >> bcache) >> o, directament, tenir un ssd "petitó" per al sistema... >> >> SALUT! >> Josep >> >>> >>> >>> Gràcies. >>> >>> -- >>> >>> Narcis Garcia >>> >>> __ >>> I'm using this dedicated address because personal addresses aren't >>> masked enough at this mail public archive. Public archive administrator >>> should fix this against automated addresses collectors. >>> >> >> >> -- >> -- >> Salutacions...Josep >> -- > > Hola, > > Almenys existeix una eina que fa el que està buscant el Narcís, es diu > e4rat i pots trobar informació al wiki de ArchLinux[1]. Tanmateix > l'eina original va quedar una mica "abandonada" i el projecte més > actiu és un fork que es diu e4rat-lite [2] > Si ho proves ja ens comentes l'experiència, i si la feina de muntar > aquestes coses val la pena per estalviar-se comprar un SSD per un > sistema antic. Amb el preu d'un SSD avui dia sembla difícil de > justificar el temps per configurar i mantenir aquestes artesanies, > però sempre és divertit pels amants de la tecnologia. > > > [1] https://wiki.archlinux.org/index.php/e4rat > [2] https://github.com/LendyZhang/e4rat-lite > > > Fins aviat, > Jordi Per aquí va la cosa. A veure quan aconsegueixo aprofitar-lo, i aconseguir després utilitzar-lo de forma una mica pràctica. Aquest tema m'ha revingut ara per aquest conversa sobre les arrencades de CD/DVD: https://lists.debian.org/debian-live/2021/02/msg00032.html
Re: (deb-cat) Desfragmentacio de l'arrencada
__ I'm using this dedicated address because personal addresses aren't masked enough at this mail public archive. Public archive administrator should fix this against automated addresses collectors. El 24/2/21 a les 10:47, Antoni Villalonga ha escrit: > On Wed, Feb 24, 2021 at 08:47:26AM +0100, Narcis Garcia wrote: >> Quan un ordinador arrenca, executa programes i aquests carreguen >> llibreries i fitxers d'arreu del volum de disc. >> Això produeix lectures aleatòries de centenars de fitxers amb els blocs >> dispersos per tota la unitat ja que, quan es desfragmenta un disc dur, >> la única cosa que s'ordena és que cada fitxer tingui els seus blocs de >> dades contínus en el disc. >> >> És a dir, podem tenir fitxers emmagatzemats com a lletres: >> A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z >> >> Però l'arrencada carrega per exemple el gestor d'arrencada (A) el qual >> carrega el sistema del nucli (B), i el qual aleshores demana fitxers >> d'arreu com R, J, Y, D, K per la qual cosa el capçal d'un disc dur no fa >> més que canviar de posició tota l'estona i fent que la càrrega sigui >> molt més lenta del què el disc seria capaç de transmetre seqüencialment. >> Això es nota molt amb el soroll d'un disc dur quan arrenca el sistema. >> >> L'ideal en aquest exemple seria poder reorganitzar els blocs del disc així: >> A,B,R,J,Y,D,K, C,E,F,G,H,I,L,M,N,O,P,Q,S,T,U,V,W,X,Z >> De manera que de la A a la K es llegís tot sense interrupció. >> >> Hi ha alguna eina que faciliti això per accelerar l'arrencada? >> >> Gràcies. > > Hola, > > Una reflexió molt interessant. La veritat és que no conec la forma de fer el > que demanes ni penso que sigui gens simple. Requeriria tenir una bona > planificació de l'ordre en que es demanaran els fitxers (més concretament els > blocs concrets que es necessitaran llegir). El manteniment també seria molt > costos, replanificant i reorganitzant a cada actualització del sistema. Evidentment el manteniment s'hauria de programar. En un altre sentit, per exemple, utilitzo el «preload» i aquest programari és el què s'ocupa de replanificar els fitxers que es llegeixen per avançat. > La tendència és a utilitzar cada cop més emmagatzaments d'accés aleatori (SSD, > etc) on aquestes penalitzacions del seek no existeixen. Un altre factor que > hauria d'alleugerar aquesta inconveniencia és l'arrencada en paraŀlel, ja que > el planificador de lectures del nucli les hauria d'agrupar de la millor forma > (minimitzant el seek time necessari). Començo a tenir dubtes sobre si realment l'accés a SSD s'està fent de manera aleatòria, quan resulta que se solen endollar amb S.ATA (*serial* ATA). La única cosa que em crec és que no hi ha un capçal mòbil; la resta imagino que ha d'haver un coll d'ampolla coordinant els canvis d'accés. Això a banda que li tinc una mica de por a la pèrdua de dades amb SSD: Ja n'he vist algun que mor, i d'allà no recuperes ni un sol bloc de dades mai més. I addicionalment: Hi ha ordinadors on Debian 10 no allibera els blocs de SSD (trim/discard) i, amb el temps, acaba tenint la mateixa velocitat que un disc rotatiu. > Per a un sistema amb disc dur (sense SSD) et proposaria fer una partició de > sistema minimalista on estigui només el que realment és necessari per a fer el > boot. La resta de software i dades podrien estar a particions distintes. > També la utilització de varis discs en RAID0 penso que ajudaria enormement. Ja havia pensat aquestes estratègies, però això només funciona amb /boot perquè tant el programari inicial com la resta resideixen als mateixos arbres de directoris. Pel què fa al RAID, és molt costós, i el què cerco és una estratègia que no només em serveixi a mi en particular. > Altres opcions podrien passar per a evitar fer el procés de boot utilitzant la > hibernació o suspensió a ram, quan es pugui. Hi ha casos en què això és fàcil i es converteix en la solució. D'altres no. > Una discusió que penso que serà eterna és el tema compilacions estàtiques vs > càrrega de biblioteques dinàmiques. La solució que intento trobar la voldré aplicar a molts ordinadors, amb la qual cosa prefereixo respectar el sistema de paquets i que no em demani un manteniment posterior. Preinstal·lar i deixar configurat. > M'agradaria llegir millors alternatives. > > Salut! >
Re: (deb-cat) Desfragmentacio de l'arrencada
El mié, 24 feb 2021 a las 10:58, Josep Lladonosa () escribió: > > > > On Wed, 24 Feb 2021 at 08:47, Narcis Garcia wrote: >> >> Quan un ordinador arrenca, executa programes i aquests carreguen >> llibreries i fitxers d'arreu del volum de disc. >> Això produeix lectures aleatòries de centenars de fitxers amb els blocs >> dispersos per tota la unitat ja que, quan es desfragmenta un disc dur, >> la única cosa que s'ordena és que cada fitxer tingui els seus blocs de >> dades contínus en el disc. >> >> És a dir, podem tenir fitxers emmagatzemats com a lletres: >> A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z >> >> Però l'arrencada carrega per exemple el gestor d'arrencada (A) el qual >> carrega el sistema del nucli (B), i el qual aleshores demana fitxers >> d'arreu com R, J, Y, D, K per la qual cosa el capçal d'un disc dur no fa >> més que canviar de posició tota l'estona i fent que la càrrega sigui >> molt més lenta del què el disc seria capaç de transmetre seqüencialment. >> Això es nota molt amb el soroll d'un disc dur quan arrenca el sistema. >> >> L'ideal en aquest exemple seria poder reorganitzar els blocs del disc així: >> A,B,R,J,Y,D,K, C,E,F,G,H,I,L,M,N,O,P,Q,S,T,U,V,W,X,Z >> De manera que de la A a la K es llegís tot sense interrupció. >> >> Hi ha alguna eina que faciliti això per accelerar l'arrencada? > > > La meva proposta passa per afegir maquinari (un ssd on el temps de > "posicionament" és molt petit i més o menys constant). > Podríeu teniri un ssd "petitó" utilitzat en forma de memòria cau (estil > bcache) > o, directament, tenir un ssd "petitó" per al sistema... > > SALUT! > Josep > >> >> >> Gràcies. >> >> -- >> >> Narcis Garcia >> >> __ >> I'm using this dedicated address because personal addresses aren't >> masked enough at this mail public archive. Public archive administrator >> should fix this against automated addresses collectors. >> > > > -- > -- > Salutacions...Josep > -- Hola, Almenys existeix una eina que fa el que està buscant el Narcís, es diu e4rat i pots trobar informació al wiki de ArchLinux[1]. Tanmateix l'eina original va quedar una mica "abandonada" i el projecte més actiu és un fork que es diu e4rat-lite [2] Si ho proves ja ens comentes l'experiència, i si la feina de muntar aquestes coses val la pena per estalviar-se comprar un SSD per un sistema antic. Amb el preu d'un SSD avui dia sembla difícil de justificar el temps per configurar i mantenir aquestes artesanies, però sempre és divertit pels amants de la tecnologia. [1] https://wiki.archlinux.org/index.php/e4rat [2] https://github.com/LendyZhang/e4rat-lite Fins aviat, Jordi -- Para ser realmente grande, hay que estar con la gente, no por encima de ella.
Re: (deb-cat) Desfragmentacio de l'arrencada
On Wed, Feb 24, 2021 at 08:47:26AM +0100, Narcis Garcia wrote: > Quan un ordinador arrenca, executa programes i aquests carreguen > llibreries i fitxers d'arreu del volum de disc. > Això produeix lectures aleatòries de centenars de fitxers amb els blocs > dispersos per tota la unitat ja que, quan es desfragmenta un disc dur, > la única cosa que s'ordena és que cada fitxer tingui els seus blocs de > dades contínus en el disc. > > És a dir, podem tenir fitxers emmagatzemats com a lletres: > A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z > > Però l'arrencada carrega per exemple el gestor d'arrencada (A) el qual > carrega el sistema del nucli (B), i el qual aleshores demana fitxers > d'arreu com R, J, Y, D, K per la qual cosa el capçal d'un disc dur no fa > més que canviar de posició tota l'estona i fent que la càrrega sigui > molt més lenta del què el disc seria capaç de transmetre seqüencialment. > Això es nota molt amb el soroll d'un disc dur quan arrenca el sistema. > > L'ideal en aquest exemple seria poder reorganitzar els blocs del disc així: > A,B,R,J,Y,D,K, C,E,F,G,H,I,L,M,N,O,P,Q,S,T,U,V,W,X,Z > De manera que de la A a la K es llegís tot sense interrupció. > > Hi ha alguna eina que faciliti això per accelerar l'arrencada? > > Gràcies. Hola, Una reflexió molt interessant. La veritat és que no conec la forma de fer el que demanes ni penso que sigui gens simple. Requeriria tenir una bona planificació de l'ordre en que es demanaran els fitxers (més concretament els blocs concrets que es necessitaran llegir). El manteniment també seria molt costos, replanificant i reorganitzant a cada actualització del sistema. La tendència és a utilitzar cada cop més emmagatzaments d'accés aleatori (SSD, etc) on aquestes penalitzacions del seek no existeixen. Un altre factor que hauria d'alleugerar aquesta inconveniencia és l'arrencada en paraŀlel, ja que el planificador de lectures del nucli les hauria d'agrupar de la millor forma (minimitzant el seek time necessari). Per a un sistema amb disc dur (sense SSD) et proposaria fer una partició de sistema minimalista on estigui només el que realment és necessari per a fer el boot. La resta de software i dades podrien estar a particions distintes. També la utilització de varis discs en RAID0 penso que ajudaria enormement. Altres opcions podrien passar per a evitar fer el procés de boot utilitzant la hibernació o suspensió a ram, quan es pugui. Una discusió que penso que serà eterna és el tema compilacions estàtiques vs càrrega de biblioteques dinàmiques. M'agradaria llegir millors alternatives. Salut! -- Antoni Villalonga https://friki.cat/
Re: (deb-cat) Desfragmentacio de l'arrencada
On Wed, 24 Feb 2021 at 08:47, Narcis Garcia wrote: > Quan un ordinador arrenca, executa programes i aquests carreguen > llibreries i fitxers d'arreu del volum de disc. > Això produeix lectures aleatòries de centenars de fitxers amb els blocs > dispersos per tota la unitat ja que, quan es desfragmenta un disc dur, > la única cosa que s'ordena és que cada fitxer tingui els seus blocs de > dades contínus en el disc. > > És a dir, podem tenir fitxers emmagatzemats com a lletres: > A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z > > Però l'arrencada carrega per exemple el gestor d'arrencada (A) el qual > carrega el sistema del nucli (B), i el qual aleshores demana fitxers > d'arreu com R, J, Y, D, K per la qual cosa el capçal d'un disc dur no fa > més que canviar de posició tota l'estona i fent que la càrrega sigui > molt més lenta del què el disc seria capaç de transmetre seqüencialment. > Això es nota molt amb el soroll d'un disc dur quan arrenca el sistema. > > L'ideal en aquest exemple seria poder reorganitzar els blocs del disc així: > A,B,R,J,Y,D,K, C,E,F,G,H,I,L,M,N,O,P,Q,S,T,U,V,W,X,Z > De manera que de la A a la K es llegís tot sense interrupció. > > Hi ha alguna eina que faciliti això per accelerar l'arrencada? > La meva proposta passa per afegir maquinari (un ssd on el temps de "posicionament" és molt petit i més o menys constant). Podríeu teniri un ssd "petitó" utilitzat en forma de memòria cau (estil bcache) o, directament, tenir un ssd "petitó" per al sistema... SALUT! Josep > > Gràcies. > > -- > > Narcis Garcia > > __ > I'm using this dedicated address because personal addresses aren't > masked enough at this mail public archive. Public archive administrator > should fix this against automated addresses collectors. > > -- -- Salutacions...Josep --
(deb-cat) Desfragmentacio de l'arrencada
Quan un ordinador arrenca, executa programes i aquests carreguen llibreries i fitxers d'arreu del volum de disc. Això produeix lectures aleatòries de centenars de fitxers amb els blocs dispersos per tota la unitat ja que, quan es desfragmenta un disc dur, la única cosa que s'ordena és que cada fitxer tingui els seus blocs de dades contínus en el disc. És a dir, podem tenir fitxers emmagatzemats com a lletres: A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z Però l'arrencada carrega per exemple el gestor d'arrencada (A) el qual carrega el sistema del nucli (B), i el qual aleshores demana fitxers d'arreu com R, J, Y, D, K per la qual cosa el capçal d'un disc dur no fa més que canviar de posició tota l'estona i fent que la càrrega sigui molt més lenta del què el disc seria capaç de transmetre seqüencialment. Això es nota molt amb el soroll d'un disc dur quan arrenca el sistema. L'ideal en aquest exemple seria poder reorganitzar els blocs del disc així: A,B,R,J,Y,D,K, C,E,F,G,H,I,L,M,N,O,P,Q,S,T,U,V,W,X,Z De manera que de la A a la K es llegís tot sense interrupció. Hi ha alguna eina que faciliti això per accelerar l'arrencada? Gràcies. -- Narcis Garcia __ I'm using this dedicated address because personal addresses aren't masked enough at this mail public archive. Public archive administrator should fix this against automated addresses collectors.
