0

Given this sequence of commands…

$ pwd
/data/backup/rsnapshot
$ sudo du -csk daily.{2,3}/ruminant
1195040 daily.2/ruminant
36712   daily.3/ruminant
1231752 total
$ ls -isk /data/backup/rsnapshot/daily.3/ruminant/home/andy/vmunix \
          /data/backup/rsnapshot/daily.3/ruminant/home/andy/vmlinux2
13344429 6728 /data/backup/rsnapshot/daily.3/ruminant/home/andy/vmlinux2
16476851 6728 /data/backup/rsnapshot/daily.3/ruminant/home/andy/vmunix
$ sudo ln -f /data/backup/rsnapshot/daily.3/ruminant/home/andy/vmunix \
             /data/backup/rsnapshot/daily.3/ruminant/home/andy/vmlinux2
$ ls -isk /data/backup/rsnapshot/daily.3/ruminant/home/andy/vmunix \
          /data/backup/rsnapshot/daily.3/ruminant/home/andy/vmlinux2
16476851 6728 /data/backup/rsnapshot/daily.3/ruminant/home/andy/vmlinux2
16476851 6728 /data/backup/rsnapshot/daily.3/ruminant/home/andy/vmunix
$ sudo du -csk daily.{2,3}/ruminant
1195040 daily.2/ruminant
36712   daily.3/ruminant
1231752 total

…why does the usage of these two directories remain at 1,231,752k after the two clearly different files are hard linked together? I would have expected /data/backup/rsnapshot/daily.3/ruminant to now be 6,728k smaller.

ext3 filesystem mounted at /data/backup, Linux Debian squeeze host.

I've checked with lsof | grep deleted that neither file is being held open by some process.

grifferz
  • 948
  • 5
  • 13
  • I think this answers it better and more eloquently than I ever could: http://stackoverflow.com/questions/19951883/du-counting-hardlinks-towards-filesize – Eddie Dunn Nov 30 '15 at 17:34
  • @EddieDunn I don't think it does because the first ```ls -isk``` command shows that the files were not hard links to begin with. – grifferz Nov 30 '15 at 17:35

1 Answers1

1

daily.2/ruminant may still contain links to the same inode (13344429), so total size hasn't gone down as the space is still allocated and in use in that directory.

A couple of related points:

a) If you had only run du -sk daily.3/ruminant then you probably would see a reduction in the total, since there are (presumably) no more links to that inode in the daily.3 directory.

b) du counts inodes as it goes in argument order, so in the first printout it assigned the usage of inode 13344429 to daily.2 rather than daily.3. Therefore removing the link from daily.3 (and leaving it in daily.2) wouldn't result in any space reduction when counting both daily.{2,3} since it's still counted in daily.2.

Dominic Cleal
  • 3,160
  • 19
  • 16
  • You are correct, there was (at least) a file **/data/backup/rsnapshot/daily.2/ruminant/home/andy/vmlinux2** with inode 13344429 so removing some other file with that inode only reduced the link count and did not in fact free up the space. Even though the two files I linked together had different inodes, there was no guarantee that there wasn't one or more other files elsewhere in the directories with the same inode as the file that got removed. – grifferz Nov 30 '15 at 18:15