-2

I have a disk that has too many small files:

df:

/dev/mapper/mpathc 6056822144 6056822144 0 100% /file3

df -i:

/dev/mapper/mpathc 384589824 12160314 372429510 4% /file3

I need to move small files on same disk like this:

mv /file3/bla/bla/23423/bla/file1.txt /file3/newpath/

But getting error like this:

mv: writing ... No space left on device

Moved some files to other disk (300GB), but df command cannot update. I must have 300GB free disk space, but I can't use.

I tried lsof command, nothing run on this disk. I tried umount and mount again, there is no change.

What can I do for use this disk spaces?

Thank you

Improve this question
15
  • 2
    Stop whatever process is still writing to your disk.
    – Michael Hampton
    Aug 15, 2016 at 7:03
  • There is no process writing to disk. I tried lsof command, there is nothing.
    – onur
    Aug 15, 2016 at 7:06
  • @phe Clean up some old junk? du -m /file3 | sort -n will find the largest files on your drive.
    – Ryan Babchishin
    Aug 15, 2016 at 7:13
  • 1
    If you can unmount and remount, then open files are not your problem. Can you touch a file? If you can, I think your problem is that you are moving files to a directory that needs to extend, and there is no place to extend. If you cannot, then did you get a read-only error? What file-system is this? If ext2/3/4 what does # dumpe2fs -h /dev/sda2 | grep '^Reserved block count' say? Is it mounted off a SAN, and if so off what make of SAN disk? Do I understand correctly that you have moved files away to another disk, that those files are no longer there, but that "df used" does not diminish?
    – Law29
    Aug 15, 2016 at 8:11
  • 1
    see this unix.stackexchange.com/questions/222221/…
    – Ijaz Ahmad
    Aug 15, 2016 at 9:51

1 Answer 1

Reset to default
5

The df and df -i reports are mixed up. The first one is from df -i, the second from df. The df -i report shows that the disk has no more inodes available, so no more files can be created on that disk, despite the df showing that the disk has plenty of space available. Inability to create inodes will cause mv to fail. To do anything on that drive, files will have to be deleted from it, by cping them onto another file system and then rming them from /file3, or similar.

Improve this answer
3
  • Are you sure about this? It doesn't make sense for a filesystem to have 384589824 blocks and 6056822144 inodes. That's more than 15x as many inodes as blocks, if what you say is true! Nearly all of those files would have to be empty.
    – Michael Hampton
    Aug 15, 2016 at 17:47
  • You are wrong. First one is from df, second one is from df -i.
    – onur
    Aug 16, 2016 at 6:21
  • Ok- if the first report is in fact from df and not df -i, then take a look at the comment on the question from @ijaz-khan pointing at unix.stackexchange.com/questions/222221/…. This may be what's blocking mv on the same file system. However, while disabling dir_index as described may allow in-file-system mv to succeed, the file system is still out of data blocks. Files will need to be moved off of the file system mounted on /file3 on to a different file system for any other work to occur.
    – Jonah Benton
    Aug 16, 2016 at 15:05

Not the answer you're looking for? Browse other questions tagged .