On 18Jan2008 08:53, Neil Bird <neil@xxxxxxxxxx> 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@xxxxxxxxxx> DoD#743 http://www.cskk.ezoshosting.com/cs/ We had the experience, but missed the meaning. - T.S. Eliot
