Onherleidbare gebruikte schijfruimte

[HarmoniousVibe]

Momenteel heb ik een mooie Samsung 830 in mijn desktop zitten met daarop een dual-boot van Arch Linux en Windows 7. Nu zag ik laatst toevallig dat mijn root wel erg veel schijfruimte in beslag nam, dus wilde ik het e.e.a. op gaan schonen.

Dit is de situatie volgens `df`:

[root@arch ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs           42G   34G  8,8G  80% /
dev             3,9G     0  3,9G   0% /dev
run             3,9G  348K  3,9G   1% /run
/dev/sda4        42G   34G  8,8G  80% /
shm             3,9G  628K  3,9G   1% /dev/shm
/dev/sda1       2,0G   19M  2,0G   1% /boot/efi
tmpfs           3,9G   96K  3,9G   1% /tmp
sonata:/         15G  9,7G  4,5G  69% /mnt/sonata
sonata:/data/    13T  7,0T  5,8T  55% /mnt/sonata/data

Nu vond ik 34GB al erg veel, zeker gezien bijna al mijn data op een NFS mount staat op mijn NAS. Het eerste wat ik altijd doe als ik schijfruimte wil vrijmaken is kijken waar de schijruimte op dit moment wordt gebruikt. En dat is waar ik voor een raadsel kom te staan:

[root@arch ~]# du -shx /
11G	/

[root@arch ~]# du -hx --max-depth=1 /
4,0K	/.config
3,0M	/bin
29M	/boot
6,8M	/etc
5,1G	/home
0	/mnt
1,3G	/opt
8,6M	/root
9,4M	/sbin
4,2G	/usr
432M	/var
0	/media
0	/srv
11G	/

In totaal kom ik dus tot slechts 11G, wat ook een veel realistischer weergave is. Dit is een verschil van 22GB! (Oor)zaken die ik kon bedenken of kon Googlen:

- Fragmentatie, aangezien ik een SSD heb heb ik nooit mijn schijf gedefragmenteerd. En dat is het probleem ook niet:

[root@arch ~]# xfs_db -c frag -r /dev/sda4
actual 235765, ideal 233250, fragmentation factor 1,07%

- Verwarring veroorzaakt door mijn NFS mount of iets met een overlay mount op /mnt/sonata/, maar dat is het ook niet, want als ik de NFS mount uit fstab haal en reboot blijft het probleem. Ook is het mountpoint /boot/efi/ gewoon leeg voordat deze wordt gemount.

- Wat ik op internet lees is dat er verwijderde files kunnen zijn die nog worden opgehouden door running processes, maar een reboot moet dat sowieso oplossen volgens mij.

Tsja, en hier houdt mijn inspiratie eigenlijk op. Heeft iemand dit probleem eerder gezien of meegemaakt?


Wat algemene info:

[root@arch ~]# xfs_info /dev/sda4 
meta-data=/dev/sda4              isize=256    agcount=4, agsize=2747861 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=10991441, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=5366, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

[root@arch ~]# cat /etc/fstab 
# 
# /etc/fstab: static file system information
#
# <file system>	<dir>	<type>	<options>	<dump>	<pass>
UUID="B626-174A" /boot/efi/ vfat defaults 0 0
UUID="64591632-4cb7-4b18-a9c5-9e0cbb8a232a" / xfs defaults,noatime,nodiratime,discard,inode64,logbufs=8,logbsize=256k 0 1
tmpfs		/tmp	tmpfs	nodev,nosuid	0	0
sonata:/	/mnt/sonata nfs defaults,user	0	0

[root@arch ~]# mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=4045032k,nr_inodes=1011258,mode=755)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/sda4 on / type xfs (rw,noatime,nodiratime,attr2,noquota)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
binfmt on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
gvfs-fuse-daemon on /home/harm/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
sonata:/ on /mnt/sonata type nfs4 (rw,nosuid,nodev,noexec,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.2,local_lock=none,addr=192.168.1.1)
sonata:/data/ on /mnt/sonata/data type nfs4 (rw,nosuid,nodev,noexec,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.2,local_lock=none,addr=192.168.1.1)

[root@arch ~]# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 250069680 sectors, 119.2 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): F2F0D994-BFAA-4B88-AB5A-5240FF75A815
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 250069646
Partitions will be aligned on 2048-sector boundaries
Total free space is 6847 sectors (3.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         2097152   1023.0 MiB  EF00  EFI System
   2         2099200         2361343   128.0 MiB   0C01  Microsoft reserved part
   3         2361344       149555199   70.2 GiB    0700  Basic data partition
   4       149555200       237486734   41.9 GiB    8300  Linux filesystem
   5       237488128       249807502   5.9 GiB     8200  Linux swap
   6       249808896       250069646   127.3 MiB   EF02  BIOS boot partition

Ik heb GPT vanwege mijn supersnelle (<10sec) EFI + GPT + SSD boot. Voor Windows is GPT een vereiste als je een EFI-boot wilt.

[root@arch ~]# uname -a
Linux arch 3.4.7-1-ARCH #1 SMP PREEMPT Sun Jul 29 22:02:56 CEST 2012 x86_64 GNU/Linux

Hopelijk snapt iemand wat hier aan de hand is!

[Hero of Time]

Start met de install CD, ga naar rescue shell en voer een fsck.xfs uit op je schijf. Wellicht heb je errors in je file system die bij 't booten niet naar voren komen door de snelle check.

[Spider.007]

HarmoniousVibe schreef op donderdag 09 augustus 2012 @ 20:01:
[...]
- Fragmentatie, aangezien ik een SSD heb heb ik nooit mijn schijf gedefragmenteerd. En dat is het probleem ook niet:

Fragmentatie is meer een 'intern' performanceprobleem van je filesystem, maar zorgt er niet voor dat je minder ruimte hebt. De gaten worden immers netjes opgevult (= gefragmenteerd)?

- Verwarring veroorzaakt door mijn NFS mount of iets met een overlay mount op /mnt/sonata/, maar dat is het ook niet, want als ik de NFS mount uit fstab haal en reboot blijft het probleem. Ook is het mountpoint /boot/efi/ gewoon leeg voordat deze wordt gemount.

Dat zou dan ook geen 'verwarring', maar gewoon corruptie zijn. Wat wel kon (dat is niet zo hier) is dat er files zitten in directories waar je nu iets anders overheen mount, waardoor die ruimte kwijt lijkt te zijn.

- Wat ik op internet lees is dat er verwijderde files kunnen zijn die nog worden opgehouden door running processes, maar een reboot moet dat sowieso oplossen volgens mij.

Klopt, dit zou je eventueel met lsof kunnen uitvogelen maar een reboot verhelpt dit sowieso. Eventueel zou je kunnen booten in runlevel 1, zodat je zeker weet dat er geen daemon is die alsnog grote hoeveelheden schijf lockt, maar dat lijkt me onwaarschijnlijk Dit is evt. te controleren met

lsof | grep deleted

Nog een mogelijkheid is dat je door veel kleine bestanden door je inodes heen bent, dat kun je bekijken met

df -i

[HarmoniousVibe]

Zal van 't weekend eens booten van een extern medium en xfs_repair doen.

Naar de inodes had ik al gegeken. Die stonden op 1% en zijn volgens mij groeien die dynamisch mee, i.t.t. bij ext4. Sowieso had ik wel hard mijn best moeten doen om met inode64 alle inodes vol te krijgen . Nogmaals, ik heb écht geen vreemde bestanden erop staan. Volledig run-of-the-mill Arch Linux-current install.

Dat van die open files had ik al gecontroleerd. Chromium heeft wat deleted temporary open files en dropbox 1 of 2, maar dat was het dan ook wel. En ik heb al vaak genoeg reboot.

[ Voor 18% gewijzigd door HarmoniousVibe op 10-08-2012 09:33 ]

[Thc_Nbl]

Probeer eens, het volgende

Unmount alle schijven / parties die niet op deze disk zitten.
unmount evt partities onderliggende

ik kwam er zelf achter dat mijn info niet klopte, na alle geunmount te hebben en weer gekeken te hebben zag het er wel goed uit, vraag me niet waarom, het heeft met gemounte partities te maken.

bij mij was het b.v.

/ in gebruik 40Gb ( in het echt maar 20 )
/db mount van een andere disk in /db die had 20Gb in gebruikt.
na unmounten van /db en weer kijken was mijn / gewoon 20Gb.

[_JGC_]

mkdir /mnt/root
mount --bind / /mnt/root

En dan nog eens kijken wat er in /mnt/root gebruikt wordt. Ik gok dat je nog data hebt staan op een plek waar nu ineens iets anders overheen gemount is.

[Saven]

schaduwkopieën van windows enzo die worden nooit in die gegevens opgenomen

[Hero of Time]

Saven schreef op maandag 20 augustus 2012 @ 00:44:
schaduwkopieën van windows enzo die worden nooit in die gegevens opgenomen

Huh? Windows? Wat is dat voor OS? Heb je ergens de broncode zodat we die zelf kunnen compileren? Kan je die vrij gebruiken?

[HarmoniousVibe]

Goed, het is opgelost, maar vraag me niet hoe:

[root@arch ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs           42G   15G   28G  34% /
dev             3,9G     0  3,9G   0% /dev
run             3,9G  348K  3,9G   1% /run
/dev/sda4        42G   15G   28G  34% /
shm             3,9G  1,2M  3,9G   1% /dev/shm
/dev/sda1       2,0G   20M  2,0G   1% /boot/efi
tmpfs           3,9G   28K  3,9G   1% /tmp

Eén van de tips die jullie met hebben gegeven heeft blijkbaar gewerkt. Mijn dank daarvoor! Ik denk zelf dat het de fsck/xfs_repair was, al gaf hij niet aan dat er iets was gerepareerd.

[Thc_Nbl]

Mount je sonata er eens weer bij en kijk opnieuw zou ik zeggen.
dan weet je of dat het een optelsom fout is in linux of dat de fsck het geregeld heeft.

Fijn dat het opgelost is.

[HarmoniousVibe]

Die verandert niets.