Étrange problème ...

Pourquoi ai-je utilisé full / partition, mais ce n'est pas vraiment utilisé?

Info rapide:

xwing ~ # df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs           16G   15G   75M 100% /
/dev/root        16G   15G   75M 100% /
devtmpfs        5,9G     0  5,9G   0% /dev
tmpfs           5,9G  552K  5,9G   1% /run
rc-svcdir       1,0M   72K  952K   8% /lib64/rc/init.d
cgroup_root      10M     0   10M   0% /sys/fs/cgroup
shm             5,9G     0  5,9G   0% /dev/shm
cachedir        4,0M  4,0K  4,0M   1% /lib64/splash/cache
/dev/sda1       124M   43M   76M  36% /boot
/dev/sda5        63G   25G   36G  42% /home
/dev/sda6       483G  147G  312G  33% /mnt/data
tmpfs           8,0G     0  8,0G   0% /var/tmp/portage

Peut-être des nœuds i? Noo ...

xwing ~ # df -i
Filesystem       Inodes  IUsed    IFree IUse% Mounted on
rootfs          1048576 548459   500117   53% /
/dev/root       1048576 548459   500117   53% /
devtmpfs        1525561    517  1525044    1% /dev
tmpfs           1525918    374  1525544    1% /run
rc-svcdir       1525918     61  1525857    1% /lib64/rc/init.d
cgroup_root     1525918      5  1525913    1% /sys/fs/cgroup
shm             1525918      1  1525917    1% /dev/shm
cachedir        1525918      2  1525916    1% /lib64/splash/cache
/dev/sda1         32768    314    32454    1% /boot
/dev/sda5       4194304 145765  4048539    4% /home
/dev/sda6      32153600  11325 32142275    1% /mnt/data
tmpfs           1525918      1  1525917    1% /var/tmp/portage

Mais:

xwing ~ # du -sxh /
8,3G    /

Peut-être que j'ai quelque chose de cassé dans la monture? (mais de toute façon, remarquez que j'ai utilisé du avec -x qui calcule les fichiers UNIQUEMENT à partir de / filesystem ...)

/ espaces ajoutés par moi pour une meilleure lisibilité /

xwing ~ # mount
rootfs      on /                        type rootfs   (rw)
/dev/root   on /                        type ext4     (rw,noatime,data=ordered)
devtmpfs    on /dev                     type devtmpfs (rw,relatime,size=6102244k,nr_inodes=1525561,mode=755)
proc        on /proc                    type proc     (rw,nosuid,nodev,noexec,relatime)
tmpfs       on /run                     type tmpfs    (rw,nosuid,nodev,relatime,mode=755)
rc-svcdir   on /lib64/rc/init.d         type tmpfs    (rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755)
sysfs       on /sys                     type sysfs    (rw,nosuid,nodev,noexec,relatime)
debugfs     on /sys/kernel/debug        type debugfs  (rw,nosuid,nodev,noexec,relatime)
cgroup_root on /sys/fs/cgroup           type tmpfs    (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755)
cpuset      on /sys/fs/cgroup/cpuset    type cgroup   (rw,nosuid,nodev,noexec,relatime,cpuset)
cpu         on /sys/fs/cgroup/cpu       type cgroup   (rw,nosuid,nodev,noexec,relatime,cpu)
cpuacct     on /sys/fs/cgroup/cpuacct   type cgroup   (rw,nosuid,nodev,noexec,relatime,cpuacct)
freezer     on /sys/fs/cgroup/freezer   type cgroup   (rw,nosuid,nodev,noexec,relatime,freezer)
devpts      on /dev/pts                 type devpts   (rw,nosuid,noexec,relatime,gid=5,mode=620)
shm         on /dev/shm                 type tmpfs    (rw,nosuid,nodev,noexec,relatime)
cachedir    on /lib64/splash/cache      type tmpfs    (rw,nosuid,nodev,noexec,noatime,size=4096k,mode=755)
/dev/sda1   on /boot                    type ext2     (rw,noatime)
/dev/sda5   on /home                    type ext4     (rw,noatime)
/dev/sda6   on /mnt/data                type ext4     (rw,noatime)
tmpfs       on /var/tmp/portage         type tmpfs    (rw,size=8G)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)

Noyau:

morsik@xwing ~ $ uname -a
Linux xwing 3.6.2-gentooxwing #8 SMP Sun Oct 21 21:36:53 CEST 2012 x86_64 Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz GenuineIntel GNU/Linux

Vraiment ... Je n'ai plus d'idées possibles à ce sujet.

Ce que j'ai essayé:

• vérifier s'il y a encore des fd ouverts après rm -rf / usr / portage / distfiles / *
• synchroniser
• redémarrer
• fsck

EDIT ET SOLUTION:

Comme toujours, j'ai trouvé une solution après avoir demandé de l'aide (-;

Monter (comme l'a dit Luke404) / partitionner ailleurs et faire du -sh / mnt / quelque chose dit qu'il y a 15G de données, donc la même chose que dans df.

Quel était le problème?

monter!

J'ai créé la partition / home plus tard, ajoutée à / etc / fstab, j'ai copié les fichiers de / home (sur / partition) vers / home (sur / partition de home) mais j'ai OUBLIÉ de supprimer les fichiers de / home sur / partition.

J'avais donc toujours mes anciens fichiers sur / home (sur / partition).

Mais pourquoi du -sxh m'a dit 8G? Facile...

-x force à ne pas vérifier différents points de montage, donc ... il n'a pas vérifié / home pendant qu'il était monté. Et il y avait ma maison manquante.

Merci à Luke404 et pidpawel qui m'ont aidé sur IRC.

Après avoir écrit cette section EDIT, j'ai vu des réponses ici, et Scrivener a obtenu le point ici!

Les problèmes stupides sont stupides (-;

Ce genre de problème est toujours très amusant.

Ma conjecture? Vous avez des fichiers sous l'un de vos points de montage. Qu'est-ce que ça veut dire? Eh bien, du -sh parcourra à la main tous les fichiers qu'il peut trouver.

Disons que j'ai un répertoire, A. Si je vide un tas de fichiers dans A, puis monte, disons, / dev / sdb au-dessus de A, df -h dira que j'ai un tas de fichiers que être capable de trouver!

Cela se produit le plus souvent avec des points de montage qui se montent et se démontent régulièrement, comme les lecteurs USB, les lecteurs réseau, etc. Il est beaucoup plus rare de le voir lorsque les montages se produisent automatiquement au démarrage, car la fenêtre pour qu'il se produise est tellement plus petite.

Avez-vous vérifié la présence de fichiers dans des endroits (actuellement) inaccessibles? Comme des choses sous /home le système de fichiers racine , que vous dune pouvez pas voir parce que vous avez monté un autre système de fichiers /home?

Vous pouvez jeter un œil à ceux-ci en fixant le système de fichiers ailleurs que dans les liens:

# mkdir /foo
# mount -o bind / /foo
# cd /foo
# du...