|
||
|
|
|
|||||||
| Samsung Galaxy S II Para hablar del Samsung Galaxy S II. También conocido como Galaxy S I9100 |
![]() |
|
|
Herramientas |
|
#1
|
||||
|
||||
|
Desfragmentación SGSII
ES una preguntilla, ¿es bueno desfragmentar las memorias del SGSII (tanto las 2 internas como la external sd)?
saludos! |
|
|
|
#2
|
||||
|
||||
|
|
|
#3
|
||||
|
||||
|
Efectivamente.
Sólo Windows fragmenta al escribir. Y las memorias no giran, por lo que no hay que desfragmentarlas. Igual que los discos SSD. ![]() Saludos |
|
#4
|
||||
|
||||
|
No olvidéis que aunque las ROM estén en ext4 (GNU/Linux) la memoria interna donde guardamos los datos y la externa están en fat32 que sufre una fragmentación brutal tanto interna como externa... Mi respuesta seria Si necesita desfragmentar cuando hayamos escrito y rescrito mucho sin formatearlas...
Última edición por aceGuanche Día 05/12/11 a las 19:27:48. |
|
#5
|
||||
|
||||
|
|
|
#7
|
||||
|
||||
|
|
|
#8
|
||||
|
||||
|
Me parece bien xq así aprendemos todos incluso sin tener un sgs ii. No olvides darle al botón "Gracias" cuando alguien te ayuda. Desde mi Z710 con Tapatalk |
|
#9
|
||||
|
||||
|
La fragmentación en discos duros es un problema porque el disco tiene que girar muchas veces para acceder a las diferentes partes que componen cada archivo, ralentizando así la lectura. En las tarjetas y discos ssd eso no influye (o influye muy poco) justamente por el tipo de acceso a los mismos que tienen, que es aleatorio. Sea Ram, o Flash, el acceso es por celda de informacion, acceso directo a una celda... Puede ser cierto que mejore minimamente la velocidad, pero hay que tener en cuenta que las tarjetas tienen una vida ciclos de escritura limitada, así que no creo que convenga hacerlo. |
| Gracias de parte de: | ||
|
#10
|
||||
|
||||
|
La que se ha liao! xD
Bueno bueno no queria montar jaleo
Solo que conecte el mvl por almacenamiento masivo y tenia un 8% de fragmentacion y queria saber si era necesario, vosotros las soleis desfragmentar?saludos! |
|
#11
|
||||
|
||||
|
Vengo de una HD2 donde parte del sistema estaba en la micro y era importante desfragmentarla. Luego se notaba menos lag, pero repito que habia parte del sistema en una partición ext4.
|
|
#12
|
||||
|
||||
|
A ver si empezamos a exponer motivos contundentes y no ideas relativas...
Hay dos tipos de Fragmentación: Interna: Se produce cuando el dato a guardar es inferior al tamaño del cluster, con su consecuente perdida de espacio. Externa: Se produce cuando los datos no se escriben de manera contigua en los cluster. La fragmentación se produce por el sistema de archivos (FILE SYSTEM) y sus características. Si fuera como ustedes comentan, que es porque los discos giran que alguien me explique ¿Por qué en EXT4 casi no hay fragmentación mientras que en FAT32 es brutal? Es totalmente ilógico lo que comentáis FAT32 se compone de varias "Zonas" Sector de arranque (Boot) Tabla de localización de ficheros (Cuales cluster se están utilizando y cuales no. Donde esta la dirección física del inicio del archivo, el final y cluster ocupa) y se compone de dos FAT1 y FAT2 la segunda en una copia de la primera por si esta falla. Directorio Raiz "Donde se guardan los nombre de los archivos y datos varios sobre ese archivo" Zona de Datos "Lo que nosotros vemos y utilizamos" Bien, los datos se escriben en los HDD o SSD según vayan quedando cluster libres, la diferencia es que en los HDD se escribe en "Cilindro" mientras en los SSD no, como es lógico ya que no es el mismo proceso. Ahora nos centraremos en los SSD, cuando hemos escrito y reescrito los archivos al dividirse para ser guardados, no pueden guardarse de manera contigua, con lo que se "Fragmenta de manera Externa" ![]() Si los datos están escritos de manera contigua los leerá mas rápido, que si están escritos en sectores no contiguos, y a la hora de escritura se escribirá mas rápido ya que no tiene que estar buscando sectores libres que han quedado sueltos por haber borrado archivos. Aquí también entra la latencia de las SD dependerá para la velocidad. Ahora también te doy el motivo de porque gasta mas batería, porque al no estar los datos guardados de manera contigua, también necesita mas ciclos de CPU para buscar y mostrar los datos en pantalla. Lo que si es cierto que no es aconsejable abusar de las herramientas de desfragmentacion en SSD por lo motivos que expone el compañero de los ciclos de escritura son limitados unos (100.000) Todo lo que he expuesto aquí lo intento explicar de la manera mas humana posible... porque es mucho mas complejo Última edición por aceGuanche Día 05/12/11 a las 22:57:30. |
| Los siguientes 4 usuarios han agradecido a aceGuanche su comentario: | ||
|
#13
|
||||
|
||||
|
Ala.....
Linux ahora resulta que hace magia también, ¿no? Vaya odio injustificado que hay hacia windows ![]() FAT (el sistema que usamos en las memorias) es más susceptible a la fragmentación que NTFS (el que usa windows desde hace años) o ext (que usa Linux). Pero vamos, que la culpa no la tiene windows. Por otro lado ya ha dicho rafacarofe todo muy correcto, así que poco más que decir. Última edición por Molitro Día 05/12/11 a las 23:01:46. |
|
#14
|
||||
|
||||
Cita:FAT (el sistema que usamos en las memorias) es más susceptible a la fragmentación que NTFS (el que usa windows desde hace años) o ext (que usa Linux). Pero vamos, que la culpa no la tiene windows.
![]() Cita:Por otro lado ya ha dicho rafacarofe todo muy correcto, así que poco más que decir.
![]()
|
|
#15
|
||||
|
||||
|
A efectos prácticos, en las memorias flash podemos ignorar la fragmentación por su muy poco efecto, sobre todo al lado de los discos mecánicos. Si nos tenemos que poner a analizar cada variable con un mínimo efecto sobre el rendimiento nos volvemos locos. Al uso de cualquier usuario, lo que ha dicho racafarofe es más que suficiente. |
|
#16
|
||||
|
||||
|
No lo comparto, sobre todo en SD de tamaño considerable... mas de 8 gigas... y vuelvo a repetir que la fragmentación es la misma en HDD que SSD, la fragmentación la produce el Sistema de Archivos por sus características...
Y si no buscamos optimizar porque usamos Custom Rom y Kernel modificados?? |
|
#17
|
||||
|
||||
|
que necedad con defragmentar... haganlo si quieren... luego comentan que resultados les da
a mi me queda claro que no es necesario hacerlo en las sd.... lo digo por la teoria que ya fue explicada ampliamente por los compañeros asi como en la practica.... cuando tuve mi hd2 con android en la sd existia en fanatismo de hacer mas rapida el acceso a android con diversos trucos, desde tener una memoria clase 10, hasta defragmentacion y programas que dizque aceleraban el acceso.... todas esas cosas a la larga eran imperceptibles, y al contrario, si dañan la memoria o en el caso de android en sd, la build completa |
|
#18
|
||||
|
||||
|
Creo que lo han dicho ya un par de veces, pero para los que insisten:
Desfragmentar una memoria flash (una SD, o un disco SSD) no sólo no es beneficioso, sino que es PERJUDICIAL. El tiempo de acceso en un disco mecánico se ve afectado por lo que tarda en desplazar el brazo mecánico de una posición a otra. Cuanto más separadas, y más desplazamientos, peor y más lento, pues el brazo necesita recolocarse cada vez. En una memoria flash, da igual: Una posición de memoria es igual a otra, es una referencia en un número y TARDA LO MISMO EN ACCEDERSE, es una descarga eléctrica, es siempre el mismo tiempo de acceso. AUNQUE ESTÉN COMPLETAMENTE FRAGMENTADAS. El hecho de que estén muy fragmentadas no afecta al rendimiento de este tipo de memorias. Ni siquiera un poquito. Ahora bien, una memoria flash tiene un número máximo de escrituras por cada bloque. Que quiere decir que tus datos sólo se pueden reescribir X veces. Y si haces una desfragmentación, le pegas un subidón de escrituras a cada sector que pa qué contarte. Vamos, que reduces la vida útil de tu memoria una burrada. Y ahí queda eso (donde pone consistent data performance, y el siguiente, defragmentation). Última edición por timonoj Día 06/12/11 a las 04:51:51. |
| Gracias de parte de: | ||
|
#19
|
||||
|
||||
|
A ver si empezamos a exponer motivos contundentes y no ideas relativas...
Hay dos tipos de Fragmentación: Interna: Se produce cuando el dato a guardar es inferior al tamaño del cluster, con su consecuente perdida de espacio. Externa: Se produce cuando los datos no se escriben de manera contigua en los cluster. ![]() La fragmentación se produce por el sistema de archivos (FILE SYSTEM) y sus características.
Si fuera como ustedes comentan, que es porque los discos giran que alguien me explique ¿Por qué en EXT4 casi no hay fragmentación mientras que en FAT32 es brutal? Es totalmente ilógico lo que comentáis ![]() Pero lo que te están diciendo no es que el giro del disco GENERE fragmentación. Te están diciendo que como CONSECUENCIA DE LA FRAGMENTACIÓN (sea quien sea el que la genera, bien FAT32, EXT4, REISERFS o quien quieras, no estamos hablando del hecho de generarla, sino de cuando ya existe), un disco giratorio se ve seriamente afectado. FAT32 se compone de varias "Zonas"
Sector de arranque (Boot) Tabla de localización de ficheros (Cuales cluster se están utilizando y cuales no. Donde esta la dirección física del inicio del archivo, el final y cluster ocupa) y se compone de dos FAT1 y FAT2 la segunda en una copia de la primera por si esta falla. Directorio Raiz "Donde se guardan los nombre de los archivos y datos varios sobre ese archivo" Zona de Datos "Lo que nosotros vemos y utilizamos" Bien, los datos se escriben en los HDD o SSD según vayan quedando cluster libres, la diferencia es que en los HDD se escribe en "Cilindro" mientras en los SSD no, como es lógico ya que no es el mismo proceso. Ahora nos centraremos en los SSD, cuando hemos escrito y reescrito los archivos al dividirse para ser guardados, no pueden guardarse de manera contigua, con lo que se "Fragmenta de manera Externa" ![]() ![]() Más o menos cierto y algo entremezclado, con algunas excepciones en lo de los cilindros, y lo de boot dependerá de la partición, aunque en todo caso todo esto no viene muy a cuento con el tema tratado. Si los datos están escritos de manera contigua los leerá mas rápido, que si están escritos en sectores no contiguos, y a la hora de escritura se escribirá mas rápido ya que no tiene que estar buscando sectores libres que han quedado sueltos por haber borrado archivos. Aquí también entra la latencia de las SD dependerá para la velocidad.
Ahora también te doy el motivo de porque gasta mas batería, porque al no estar los datos guardados de manera contigua, también necesita mas ciclos de CPU para buscar y mostrar los datos en pantalla. ![]() ¿Qué más da pedirle a la memoria la dirección 00567888 y luego la 00567889, que pedir 00567888 y luego 65432312? El tiempo de respuesta viene, como siempre, determinado por la latencia de la memoria, y es siempre el mismo. No tiene un "cursor" que mover "buscando" nada. Se pide un número, y da por respuesta los datos del bloque acorde, siempre tras el mismo período de tiempo. Aunque estén cada uno en una punta, los datos tardan siempre lo mismo en salir. No hay que gastar ni más energía, ni más tiempo, y ahí está la gracia de las memorias sólidas. Última edición por timonoj Día 06/12/11 a las 05:13:53. |
| Los siguientes 3 usuarios han agradecido a su comentario: | ||
|
|
|
#20
|
||||
|
||||
|
Entonces por qué pasa esto??
Antes ![]() Después ![]() No tengo la verdad absoluta y entiendo todo lo que decís, pero las pruebas me dicen que después de desfragmentar, el rendimiento y la estabilidad de la SD mejora... |