sauvegarde sous linux - Page 2

dd: seek: illegal numeric value



Hum non bon ok
non marche pas sur du HFS+ ^^

dd seek=1024g bs=1 count=1 </dev/zero > test 
^C^C^C^C^C^C^C^C^C^C^C^C1+0 records in
0+0 records out
0 bytes transferred in 4.152116 secs (0 bytes/sec)

les ctrl+c c'est des le moment ou j'ai vu que le fichier me remplissait le disque et que j'allait rentrer dans un mode qui faut eviter ^^

Ca marche au moins sur ext reiserfs jfs et ufs (donc les systèmes à base de Linux, de *BSD, de IBM AIX - ça inclue les mac s'ils sont installés avec ufs au lieu de hfs).
Et c'est en adéquation avec la norme posix.

On remarque aussi que NTFS supporte en théorie les fichiers à trous mais curieusement, je sais pas si c'est le driver qui le gère pas ou si faut changer un truc dans la config, ça ne marche pas, de base en tous cas.

En fait le seul vrai défaut de ce système c'est qu'il n'existe pas de fonction permettant de libérer l'espace après avoir écrit dessus (le "unmap" si on fait l'analogie à une zone mémoire). Enfin y'a bien truncate mais ça ne marche qu'avec la fin du fichier, pas moyen de lui dire que tu veux "unmapper" les blocs 1293 à 4365.

marrant le fichier creux de 1 To

Extended > Merci !

Tiens pour les intéressés, j'en ai profité pour chercher pourquoi même avec du NTFS les fichiers à trous ne sont jamais utilisés.
En fait il faut que le programme qui crée le fichier en fasse la demande explicite =>

HANDLE hFile = ::CreateFile("file.bin", GENERIC_WRITE, 0, NULL, CREATE_NEW, FILE_ATTRIBUTE_NORMAL, NULL);

DWORD dwTemp;
DeviceIoControl(hFile, FSCTL_SET_SPARSE, NULL, 0, NULL, 0, &dwTemp, NULL);

(tiens je viens d'avoir une grosse interaction fichier de 1To/samba/backup simultané qui m'a fait perdre la moitié de mon ~ ) heureusement que j'ai fait mon backup bourrin y'a 1/4 d'heure tiens