Migration NTFS -> EXT4, où sont passés 120 Go?

wim@wim-ubuntu:~/Desktop$ mount | grep media
/dev/sdc1 on /media/data type ext4 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdb1 on /media/wd type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096,default_permissions)
wim@wim-ubuntu:~/Desktop$ df | grep media
/dev/sdc1            1922858352 1824822680    360072 100% /media/data
/dev/sdb1            1953512000 1825392384 128119616  94% /media/wd
wim@wim-ubuntu:~/Desktop$ df -h | grep media
/dev/sdc1             1.8T  1.7T  352M 100% /media/data
/dev/sdb1             1.9T  1.8T  123G  94% /media/wd

Je déplace mes données d'un lecteur NTFS vers un lecteur ext4. Sur le volume NTFS, j'avais 122,2 Go d'espace libre, puis après avoir copié avec rsync (à l'exclusion de quelques fichiers NTFS inutiles System Volume Information), je n'ai que 351,6 Mo d'espace libre.

Les disques durs sont des disques WD 2 To identiques. J'ai créé la partition EXT4 avec gparted, y a-t-il une raison pour laquelle l'ext4 aurait 30653648 blocs en moins dessus?

Sortie de sudo fdisk -l:

Disk /dev/sdc: 2000.4 GB, 2000397852160 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00bb4cbc

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1      243201  1953512001   83  Linux

Disk /dev/sdb: 2000.4 GB, 2000397852160 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xcefa6110

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1      243201  1953512001    7  HPFS/NTFS

Après quelques tripotages, j'ai pu récupérer une grande quantité d'espace avec tune2fs:

wim@wim-ubuntu:~/Desktop$ df -h | grep sdc
/dev/sdc1             1.8T  1.7T  352M 100% /media/data
wim@wim-ubuntu:~/Desktop$ sudo tune2fs -l /dev/sdc1 | grep 'Reserved block count'
Reserved block count:     24418900
wim@wim-ubuntu:~/Desktop$ sudo tune2fs -m 0 /dev/sdc1
tune2fs 1.41.14 (22-Dec-2010)
Setting reserved blocks percentage to 0% (0 blocks)
wim@wim-ubuntu:~/Desktop$ sudo tune2fs -l /dev/sdc1 | grep 'Reserved block count'
Reserved block count:     0
wim@wim-ubuntu:~/Desktop$ df -h | grep sdc
/dev/sdc1             1.8T  1.7T   94G  95% /media/data

Apparemment, Linux réserve 5% des nouvelles partitions pour l'utilisateur root et les services système, de sorte que lorsque vous manquez d'espace disque, root peut toujours se connecter et nettoyer les choses avec les services système fonctionnant correctement. Semble sorte de bananes pour moi quand les services système ne ont besoin d' une centaine de meg environ , et 5% d'un lecteur de 2To est un h17load de $ plus que cela .. hausse les épaules

Cela m'a laissé avec 93,5 Go de libre, ce qui laisse encore environ 30 gig sans compte, donc si quelqu'un a d'autres idées, n'hésitez pas à y participer!

Avez-vous resynchronisé vos fichiers en utilisant également l'option -H? Il peut y avoir des liens durs sur le lecteur source, ce qui entraînera la duplication du contenu sur la destination, sauf si vous spécifiez rsync pour (essayer de) conserver les liens durs.

Cela est particulièrement vrai pour, par exemple, la partition système de Windows 7 et Windows / winsxs (Windows côte à côte), qui contient de nombreux liens durs vers des fichiers dans la hiérarchie des répertoires.

Utilisez l'analyseur d'espace disque fourni avec l'installation Ubuntu par défaut. Il vous montrera exactement où l'espace est utilisé.

les 30 Go n'existent peut-être pas vraiment. un Go est techniquement 1024 octets. différents systèmes d'exploitation peuvent compter cela différemment, soit 1024 comme c'est correct, soit simplement 1000 (appelés GiB, mais nous les utilisons interchangeables). cela peut entraîner un 1 To apparaissant dans Windows comme seulement 931 Go (expérience personnelle). les gens demandent où les 60 Go supplémentaires sont allés, la vérité est qu'ils ne sont allés nulle part, ils ne sont tout simplement pas comptés correctement. donc votre 30 Go peut être simplement un problème de fenêtres et Linux aime le compter différemment, que ce soit 1000 ou 1024. maintenant cela ne fait pas une grande différence uniquement en gigaoctets, mais permet de l'étendre. ces 24 octets supplémentaires font une différence. maintenant étendu, parfois un To est compté comme 1 000 000 000 000 octets. contre 1 099 511 627 776 octets. maintenant cette différence s'élève à environ 92 Go (techniquement GiB lol). j'espère que cela a aidé, c'est une question que je vois beaucoup honnêtement. "Où est passé tout mon stockage?"