1

For about a day now I can only create/cp/mv (through terminal or various GUI programs) files on my FAT16 formatted USB stick, of about a few bytes. Doing so with larger files reports cannot create regular file 'XXX': No space left on device

I have a NTFS drive, and a USB stick with 2 FAT16 formatted partitions on it, attached to the computer.

  • /dev/sda1 is the NTFS
  • /dev/sdb1 is one of the FAT 16 formatted partitions
  • /dev/sdc1 is the other the FAT 16 formatted partitions (Prior and after unplugging the USB stick while PC was pm-suspend'd, to clear space on the full drive - Seems this may have caused part/all of this issue in hindsight)
  • /dev/sdb1 is the other the FAT 16 formatted partitions (After unplugging the USB stick while PC was pm-suspend'd

df reported:

    Filesystem  1K-blocks   Used   Available  Use%  Mounted on
    /dev/sdc1    1999360  1999360      0      100%  /media/sdc1
    /dev/sdd1    1999360   822400   1176960   42%   /media/sdd1

df -i reported:

    Filesystem  Inodes  IUsed  IFree  IUse%  Mounted on
    /dev/sdc1      0      0      0      -    /media/sdc1
    /dev/sdd1      0      0      0      -    /media/sdd1

Sub question: Any idea why there are no inodes reported??

df -i /dev/sda1 reported:

    Filesystem  Inodes   IUsed   IFree    IUse%  Mounted on
    /dev/sda1   5539908  171718  5368190    4%   /media/sda1

umount'ng /dev/sdc1 didn't change the counts.

I have verified through Windows that space available more-or-less marries with the 42% listed for the latest mounted device (/dev/sdd1).

Any ideas on what is going on?

Edit 1:

The output of du -k --max-depth=1 /media/sdc1 is:

   1856 /media/sdc1/dir1
     32 /media/sdc1/dir2
   1440 /media/sdc1/dir3
  18144 /media/sdc1/dir4
   8512 /media/sdc1/dir5
  54304 /media/sdc1/dir6
   3200 /media/sdc1/dir7
  27200 /media/sdc1/dir8
  41088 /media/sdc1/dir9
  11520 /media/sdc1/dir10
    128 /media/sdc1/dir11
    128 /media/sdc1/dir12
   1216 /media/sdc1/dir13
   2464 /media/sdc1/dir14
  12032 /media/sdc1/dir15
   5824 /media/sdc1/dir16
  29600 /media/sdc1/dir17
  20928 /media/sdc1/dir18
   5856 /media/sdc1/dir19
   4352 /media/sdc1/dir20
 659200 /media/sdc1/dir21
 121600 /media/sdc1/dir22
  22688 /media/sdc1/dir23
    128 /media/sdc1/dir24
   2144 /media/sdc1/dir25
   6912 /media/sdc1/dir26
  19968 /media/sdc1/dir27
   9632 /media/sdc1/dir28
    960 /media/sdc1/dir29
   1088 /media/sdc1/dir30
   2624 /media/sdc1/dir31
    480 /media/sdc1/dir32
1142944 /media/sdc1
user66001
  • 2,325
  • 4
  • 19
  • 27
  • Does this persist after a reboot? – terdon Jun 08 '13 at 16:10
  • Unfortunately I can't reboot as am on a live CD mounted distro, and the flash drive is the only clean FS to write important data to. – user66001 Jun 08 '13 at 16:16
  • What is the output of `du -k --max-depth=1 /media/sdc1`? – Hauke Laging Jun 08 '13 at 16:17
  • 1856 /media/sdc1/ 32 /media/sdc1/ 1440 /media/sdc1/ 18144 /media/sdc1/ 8512 /media/sdc1/ 54304 /media/sdc1/ 3200 /media/sdc1/ 27200 /media/sdc1/ 41088 /media/sdc1/ 11520 /media/sdc1/ 128 /media/sdc1/ 128 /media/sdc1/ 1216 /media/sdc1/ 2464 /media/sdc1/ 12032 /media/sdc1/ 5824 /media/sdc1/ 29600 /media/sdc1/ 20928 /media/sdc1/ 5856 /media/sdc1/ 4352 /media/sdc1/ 659200 /media/sdc1/ 121600 /media/sdc1/ 22688 /media/sdc1/ 128 /media/sdc1/ 2144 /media/sdc1/ 6912 /media/sdc1/ 19968 /media/sdc1/ 9632 /media/sdc1/ 960 /media/sdc1/ 1088 /media/sdc1/ 2624/media/sdc1/ 480/media/sdc1/ 1142944 /media/sdc1 – user66001 Jun 08 '13 at 16:41
  • Directory names removed to fit into comment + for privacy. – user66001 Jun 08 '13 at 16:41
  • Such output is not supposed for comments but for an edit of the question. If you cannot reboot can you at least `umount` and `fsck` `sdc1`? – Hauke Laging Jun 08 '13 at 17:01
  • I think I might have found something... If I delete 1-2 long filenamed files, I can create varying length files, as long as the length of their filenames doesn't exceed the length of the deleted files filename lengths. I am aware that there is a limit to the amount of files that can be stored on the root of certain FS (Does anyone know how to see what that limit is in, on any particular FS, in Linux?), but perhaps there is also a limit on the filename lengths in the root/any particular directory (Would be good to know if there is any way of discovering what that is, in Linux, also?)... – user66001 Jun 08 '13 at 17:27

2 Answers2

2

FAT16 can hold a very limited number of files on the root directory. My guess is that you are hitting that. Create a directory and put files in it.

Riccardo De Menna
  • 21
  • 2
  • Thanks Riccardo De Menna. After all the back & forth with [hauke-laging](http://unix.stackexchange.com/users/32191), in the comments, this question has morphed into answering - [As I have longer than 8.3 filenames in use, and given the ~30 files in the root directory, think this has more to do with the hidden directories I understand are created to deal with the long file/directory names in FAT filesystems. So, hHow to use Linux tools to discover "raw" file+directory count?](http://unix.stackexchange.com/questions/78710/#comment115730_78712) – user66001 Aug 09 '13 at 13:43
1

There are no inodes on most non-Unix file systems (like vfat). It's normal that none are shown. For the rest of the problem we need more info.

Edit 1:

From the du output we now know that there are 1999360-1142944=856416 blocks missing. With Linux file systems such differences can occur if an open file is deleted. You do not see it in the file system any more (thus du cannot count it). ... In order to make this less theoretical I just gave it a try: It's the same on vfat. You can find deleted open files with this command (as root):

find /proc/*/fd -lname '/media/sdc1/* (deleted)'

The other possibility are file system errors. Thus if you cannot identify deleted open files as the problem then it would be good if you could unmount and check the file system.

Hauke Laging
  • 88,146
  • 18
  • 125
  • 174
  • As stated, /dev/sda1 is NTFS, and is reporting iNodes. – user66001 Jun 08 '13 at 16:17
  • @user66001 OK, "non-Unix" was too broad then. vfat doesn't though. I checked that before. – Hauke Laging Jun 08 '13 at 16:19
  • Okay, so seeing as fat16 is now excluded from your statement, any ideas as to why no inodes are showing? – user66001 Jun 08 '13 at 16:38
  • @user66001 Why should fat16 be excluded from my statement? – Hauke Laging Jun 08 '13 at 16:48
  • Actually, you are correct. What other info do you need for the actual problem of being unable to write to the drive? – user66001 Jun 08 '13 at 16:58
  • Thanks for your help thusfar Hauke Laging. That command ?cancels? with `find: '/proc/self/fd/5': No such file or directory` – user66001 Jun 08 '13 at 17:21
  • @user66001 You're welcome. And I always like upvotes... So it seems that the problem is not due to intransparently covered space. But according to your comment you have found the real problem. – Hauke Laging Jun 08 '13 at 18:38
  • Found a symptom of the problem yes, but still need to find a way to confirm it - (From further reading) How to find out the maximum number of "fake" directories are in use to accommodate the larger than 8.3 filenames? Or the actual number of directories in use on any particular FAT filesystem? – user66001 Jun 08 '13 at 18:52
  • @user66001 This may not be related to Linux (vfat implementation) any more but to the (non-Linux) file system itself. So you may get better answers to that detail on other sites (Superuser or maybe there is one for Windows or file systems). – Hauke Laging Jun 08 '13 at 19:26
  • 1
    I would agree if I wanted to use another OS's tools to gather this info, but I want to use Linux tools, with the Linux drivers that are facilitating access to the FS and adhering to the rules of it. Perhaps I should try starting a new question with just this subject. – user66001 Jun 08 '13 at 19:43