Pregunta

Considere un archivo disperso con 1s escritos a una parte del archivo.

Quiero recuperar el espacio real en el disco para estos 1s que ya no necesito esa porción del archivo disperso. La parte del archivo que contiene estos 1s debe convertirse en un "agujero" como lo era antes de que los mismos fueron escritos 1s.

Para hacer esto, se aclaró la región a 0s. Esto hace no reclamar los bloques en el disco.

¿Cómo hacer realidad el archivo disperso, así, escaso de nuevo?

Esta pregunta es similar a éste pero no hay una respuesta aceptada para esa pregunta.

Tenga en cuenta la siguiente secuencia de eventos se ejecutan en un servidor de Linux:

$ cat /tmp/test.c
#include <unistd.h>
#include <stdio.h>
#include <fcntl.h>
#include <string.h>

int main(int argc, char **argv) {
    int fd;
    char c[1024];

    memset(c,argc==1,1024);

    fd = open("test",O_CREAT|O_WRONLY,0777);
    lseek(fd,10000,SEEK_SET);
    write(fd,c,1024);
    close(fd);

    return 0;
}

$ gcc -o /tmp/test /tmp/test.c

$ /tmp/test

$ hexdump -C ./test
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00002710  01 01 01 01 01 01 01 01  01 01 01 01 01 01 01 01  |................|
*
00002b10

$ du -B1 test; du -B1 --apparent-size test
4096        test
11024       test

$ /tmp/test clear

$ hexdump -C ./test
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00002b10

$ du -B1 test; du -B1 --apparent-size test
4096        test
11024       test

# NO CHANGE IN SIZE.... HMM....

EDITAR -

Déjeme calificar, además, que no quiero volver a escribir archivos, copiar archivos, etc. Si no es posible bloques de alguna manera previamente asignados In situ , que así sea, pero yo' d como para determinar si tal es realmente posible o no. Parece que "no, no lo es" en este punto. Supongo que estoy buscando sys_punchhole para Linux (discusiones de los cuales Me tropecé).

¿Fue útil?

Solución

En este momento parece que sólo NTFS admite perforación de orificios. Esto ha sido históricamente un problema en la mayoría de los sistemas de ficheros. POSIX por lo que yo sé, no define una interfaz de sistema operativo para perforar agujeros, por lo que ninguno de los sistemas de archivos estándar de Linux tiene soporte para el mismo. NetApp apoya la perforación de orificios a través de Windows en su WAFL sistema de archivos. Hay un buen post sobre este aquí .

Para su problema, como otros han señalado, la única solución es mover el archivo dejando de bloques que contienen ceros. Sí que va a ser lento. O escribir una extensión para el sistema de ficheros en Linux que hace esto y presentará un parche a la buena gente en el equipo del kernel de Linux. ;)

Editar: Parece como XFS soporta perforación de orificios. Compruebe este hilo .

Otra opción muy retorcida puede ser el uso de un sistema de archivos depurador ir y ponche agujeros en todos los bloques indirectos que apuntan a llevado a cero bloques en su archivo (tal vez usted puede crear scripts para eso). A continuación, ejecute fsck que corregirá todos los números de bloques asociados, bloques de recoger todos los huérfanos (los) puesto a cero y ponerlos en los perdidos + found (puede eliminarlos para recuperar espacio) y corregir otras propiedades en el sistema de archivos. Miedo, ¿eh?


Renuncia: Haz esto a su propio riesgo. No soy responsable de ninguna pérdida de datos en los que incurra ;).

Otros consejos

Parece como si Linux han añadido una llamada al sistema llamado fallocate de "agujeros de perforación" en los archivos. Las implementaciones de sistemas de ficheros individuales parecen centrarse en la capacidad de utilizar esto para pre-asignación de un número mayor de bloques continua.

También existe la llamada posix_fallocate que sólo se centran en este último, y no se puede utilizar para perforar orificios laterales.

Ron Yorston ofrece varias soluciones; pero todos ellos implican ya sea montar el FS de sólo lectura (o desmontarlo), mientras que el sparsifying se lleva a cabo; o hacer un nuevo archivo disperso, a continuación, copiando a través de esas porciones del original que no sólo son 0s, y luego reemplazar el archivo original con el archivo recién sparsified.

En realidad depende de su sistema de ficheros sin embargo. Ya hemos visto que se encarga de esta NTFS. Me imagino que cualquiera de los otros sistemas de ficheros listas Wikipedia como el manejo de compresión transparente haría exactamente el mismo - esto es, después de todo, lo que equivale a comprimir el archivo de forma transparente.

Después de haber "puesto a cero" alguna región del archivo que tiene que decirle al sistema de archivos que esta nueva región está destinada a ser una región escasa. Por lo que en caso de NTFS tiene que llamar Dispositivo () para esa región de nuevo. Al menos hago de esta manera en mi utilidad: "sparse_checker"

Para mí el mayor problema es la forma en que ha decidido eliminar la parte posterior región de escasa:.)

Regards

De esta manera es barato, pero funciona. :-P

  1. Leer en todos los datos más allá del agujero desea, en la memoria (o en otro archivo, o lo que sea).
  2. truncar el archivo en el inicio de la perforación (ftruncate es su amigo).
  3. Seek al extremo del agujero.
  4. Escribir en la parte trasera de datos.

umount su sistema de archivos y edición de sistema de archivos directamente en forma debugfs o fsck similares. por lo general necesita controlador para cada fs usados.

Parece que escribir ceros (como en la pregunta que se hace referencia) a la parte que haya terminado con una cosa es lógico tratar. Aquí un enlace a una pregunta de MSDN para archivos NTFS escasa que hace precisamente eso a la parte de "liberación" "sin usar". Tu caso es distinto.

http://msdn.microsoft.com/en-us/library /ms810500.aspx

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top