web-dev-qa-db-fra.com

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 disponibles, puis après la copie avec rsync (à l’exception de quelques fichiers NTFS inutiles dans 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. Existe-t-il une quelconque raison pour laquelle l'ext4 aurait 30653648 moins de blocs?

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
9
wim

Après quelques manipulations, 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 aux utilisateurs racine et aux services système. Ainsi, lorsque vous manquez d'espace disque, root peut toujours se connecter et nettoyer les services système fonctionnant correctement. Cela me semble une sorte de banane quand les services du système n’ont besoin que d’une centaine de Mo, et que 5% d’un disque dur de 2 To est un chargement de $ 17 de plus que cela .. hausse les épaules

Cela me laisse 93,5 Go gratuits, ce qui laisse encore environ 30 Go de compte, alors si quelqu'un a plus d'idées, n'hésitez pas à participer!

9
wim

Avez-vous synchronisé vos fichiers en utilisant également l'option -H? Il peut y avoir des liens en dur sur le lecteur source, ce qui entraînera la duplication du contenu de la destination, à moins que vous ne spécifiiez rsync pour (essayer de) préserver les liens en dur.

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

3
pullmoll

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

0
Jo-Erlend Schinstad

les 30 Go peuvent ne pas exister vraiment. un Go est techniquement 1024 octets. Différents systèmes d'exploitation peuvent compter cela différemment, soit de 1024 soit comme il convient, soit simplement de 1000 (appelé un GiB, mais nous les utilisons de manière interchagable). Cela peut entraîner un 1 To apparaissant dans Windows comme seulement 931 Go (expérience personnelle). les gens demandent où les 60gb 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, vos 30 Go peuvent simplement être un problème de Windows et Linux aiment le compter différemment, que ce soit 1000 ou 1024. Maintenant, cela ne fait pas une grande différence lorsque seulement en gigaoctets, mais permet de le redimensionner. ces 24 octets supplémentaires font une différence. maintenant à l'échelle, parfois un TB compte pour 1 000 000 000 000 octets. par rapport à 1 099 511 627 776 octets. Maintenant, cette différence est d'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?"

0
skyler