
Estoy buscando una manera de ocupar espacio en un sistema de archivos AIX sin realizar muchas E/S.
Lo he probado dd
y lmktemp
. dd
crea un archivo disperso, pero no bloquea el espacio. lmktemp
hace bien el trabajo pero hay algo de IO y lleva un poco de tiempo. Creo fallocate
que es rápido y sin IO.
Respuesta1
La respuesta literal a su pregunta es: No, AIX no proporciona ese comando fallido. AIX proporciona la llamada de biblioteca posix_fallocate().
Para más detalles:
root@x066:[/data/prj/python/python3-3.6.8]find /usr/include -name \*.h | xargs egrep "(fallocate|truncate)64\("
/usr/include/unistd.h: extern int ftruncate64(int, off64_t);
/usr/include/unistd.h: extern int truncate64(const char *, off64_t);
root@x066:[/data/prj/python/python3-3.6.8]find /usr/include -name \*.h | xargs egrep "(fallocate|truncate)\("
/usr/include/fcntl.h:extern int posix_fallocate(int,off_t,off_t);
/usr/include/sys/fp_io.h:fp_ftruncate( struct file *fp,
/usr/include/sys/fp_io.h:extern int fp_ftruncate();
/usr/include/unistd.h: extern int ftruncate();
/usr/include/unistd.h: extern int truncate();
/usr/include/unistd.h: extern int ftruncate(int, off_t);
/usr/include/unistd.h: extern int truncate(const char *, off_t);
En cuanto a dd, proporcionar un archivo "escaso" y no bloquear espacio. Según tengo entendido, esa es la definición de archivo "escaso": espacio lógico ocupado, no espacio físico. Además, re: dd, si no se proporciona ningún argumento de "búsqueda", entonces el archivo no debería ser escaso, pero requerirá tiempo y esfuerzo por parte de los subsistemas de IO.
Sí, mucho más tarde con una respuesta, pero eso se debe a que estoy investigando falocate en AIX y un posible error que encontré en una aplicación que usa fallocate() (¡la llamada!, en realidad posix_fallocate()) en AIX.
¡Espero que esto ayude!
Respuesta2
Puede utilizar las llamadas de la familia truncate() (ftruncate(), etc.) no sólo para reducir, sino también para expandir archivos. Simplemente "truncarlos" a un tamaño mayor que el actual. En los sistemas de archivos que admiten archivos con agujeros, será rápido, mucho más rápido que agregar los bloques nulos requeridos al final de los archivos.