df not reporting correct free space - hard link problems?

[Cameron Simpson]

On 18Jan2008 08:53, Neil Bird <neil at fnxweb.com> wrote:
>   On my (ext3, LVM) drive on which I perform backups, I went to copy a 
> large directory and starting getting loads of out-of-space errors,

Using what precise copy command?

> even 
> though 'df' reports plenty of room, even to non-root users.
> $ df -h /usr/backup
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/mapper/sata0-backup
>                       464G  367G   88G  81% /usr/backup
> .. but:
> mv: cannot create regular file `blah': No space left on device

"mv" is not a copy command. And I don't think it prserves hard links.

>   Now, I am using rsync to create daily+weekly backups on that drive, so 
> there are wads of hard links to things several times over.  But 'df' should 
> be able to cope with that, shouldn't it?

Df copes just fine. But mv-ing a tree with lots of hard links to another
filesystem almost certainly makes separate copies of each link, at vast disc
space expense. It also doesn't cope with sparse files, though you probably
don't have any.

>   I ran a forced fsck on the drive, but that reported no problems.  Any 
> ideas anyone?

Hard links in source. No hard links in destination. "ls -i" can show
this, example:

  ls -ldi /src/file1 /src/file2
  ls -ldi /dst/file1 /dst/file2

Presuming file1 and file2 were hard links in /src/, they will have the
same inode number. If they are two different inode numbers in /dst/ then
they are two copies, consuming twice the space. There's a link count
column in "ls -l", too, which will show this effect.

You're using the wrong copy command. Try this:

  mkdir /path/to/target
  rsync -aH /path/to/source/ /path/to/target/

Note the "H" option - it is vital.

In short, df _is_ reporting correct free space. You're using space up
faster that you imagined.
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

We had the experience, but missed the meaning.  - T.S. Eliot