56

I am running a Python script that is causing the above error. The unusual thing is this script is running on a different machine and is having no problems.

The difference is that on the machine that is causing the problems I am writing to an external hard drive. To make things even weirder this script has run on the problem machine and already written over 30,000 files.

Some relevant information (The code that is causing the error):

nPage = 0
while nPage != -1:
    for d in data:
        if len(d.contents) > 1:
            if '<script' in str(d.contents):
                l = str(d.contents[1])
                start = l.find('http://')
                end = l.find('>',start)
                out = get_records.openURL(l[start:end])
                print COUNT

                with open('../results/'+str(COUNT)+'.html','w') as f:
                    f.write(out)
                COUNT += 1

    nPage = nextPage(mOut,False)

The directory I'm writing to:

10:32@lorax:~/econ/estc/bin$ ll ../
total 56
drwxr-xr-x 3 boincuser boincuser  4096 2011-07-31 14:29 ./
drwxr-xr-x 3 boincuser boincuser  4096 2011-07-31 14:20 ../
drwxr-xr-x 2 boincuser boincuser  4096 2011-08-09 10:38 bin/
lrwxrwxrwx 1 boincuser boincuser    47 2011-07-31 14:21 results -> /media/cavalry/server_backup/econ/estc/results//
-rw-r--r-- 1 boincuser boincuser 44759 2011-08-09 10:32 test.html

Proof there is enough space:

10:38@lorax:~/econ/estc/bin$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             9.0G  5.3G  3.3G  63% /
none                  495M  348K  495M   1% /dev
none                  500M  164K  500M   1% /dev/shm
none                  500M  340K  500M   1% /var/run
none                  500M     0  500M   0% /var/lock
none                  9.0G  5.3G  3.3G  63% /var/lib/ureadahead/debugfs
/dev/sdc10            466G  223G  244G  48% /media/cavalry

Some things I have tried:

  • Changing the path of the write to the direct location instead of going through the link
  • Rebooting the machine
  • Unmounting and re-mounting the drive
Giacomo1968
  • 25,759
  • 11
  • 71
  • 103
josh
  • 1,544
  • 2
  • 16
  • 27
  • What kind of file system is `/media/cavalry`? Maybe you could post the relevant line from `/proc/mounts`. Are you simply running out of inodes? – Sven Marnach Aug 09 '11 at 14:48
  • 4
    It would be helpful if you included full traceback (on which line the error occurred?), filesystem types and free inode count (`df -i`). In this case, I suspect the filesystem is `vfat` and you've exceeded the maximum number of files in a directory. – Rosh Oxymoron Aug 09 '11 at 14:53
  • @Rosh - +1 - see that the filename is 32766 - that number sets off alarms :) btw, you should move your comment to answers – KevinDTimm Aug 09 '11 at 15:04
  • 1
    32766 + "." + ".." for 32768 directory entries. Hmm... – wberry Aug 09 '11 at 15:53
  • @Rosh Yes there are no more inodes. Interesting. Rosh if you post your comment to an answer I can list that as the choice. But I'm also wondering what I can do to rectify this and where I can get some more information on inodes in the vfat system. Thanks! – josh Aug 09 '11 at 16:29
  • Ok I meant to post this with the last comment:
    Filesystem Inodes IUsed IFree IUse% Mounted on
    /dev/sdc10 0 0 0 - /media/cavalry
    Seems odd that is says there are no Inodes at all. Is definitely vfat:
    /dev/sdc10 /media/cavalry vfat rw,nosuid,nodev,noexec,relatime,uid=1001,gid=1001,fmask=0113,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0
    – josh Aug 09 '11 at 16:42
  • I have a similar error, in python3.7.4, Centos 7.7.1908。I run code in `ipython`, raise the error but ipython interpreter don't crash. then I chechout disk capacity and inode with `df -hi`, These parameters are OK。Then use `lsof +L1` and find many file descritor that NLINK is 0, that because I deleted an open file directly, They're going to keep using the disk until the process exits。the `df` don't show correct message because it read the superblock from disk。so you can exit your process or modify code, Especially file descriptors。 – libin Dec 09 '19 at 10:09

9 Answers9

70

The ENOSPC ("No space left on device") error will be triggered in any situation in which the data or the metadata associated with an I/O operation can't be written down anywhere because of lack of space. This doesn't always mean disk space – it could mean physical disk space, logical space (e.g. maximum file length), space in a certain data structure or address space. For example you can get it if there isn't space in the directory table (vfat) or there aren't any inodes left. It roughly means “I can't find where to write this down”.

Particularly in Python, this can happen on any write I/O operation. It can happen during f.write, but it can also happen on open, on f.flush and even on f.close. Where it happened provides a vital clue for the reason that it did – if it happened on open there wasn't enough space to write the metadata for the entry, if it happened during f.write, f.flush or f.close there wasn't enough disk space left or you've exceeded the maximum file size.

If the filesystem in the given directory is vfat you'd hit the maximum file limit at about the same time that you did. The limit is supposed to be 2^16 directory entries, but if I recall correctly some other factors can affect it (e.g. some files require more than one entry).

It would be best to avoid creating so many files in a directory. Few filesystems handle so many directory entries with ease. Unless you're certain that your filesystem deals well with many files in a directory, you can consider another strategy (e.g. create more directories).

P.S. Also do not trust the remaining disk space – some file systems reserve some space for root and others miscalculate the free space and give you a number that just isn't true.

Rosh Oxymoron
  • 20,355
  • 6
  • 41
  • 43
  • First, this is happening on "open" line. Second, I mean to post this with my last comment:Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sdc10 0 0 0 - /media/cavalry. So, it looks like I don't have any Inodes but also that I'm not using any. As for making more directories wouldn't that kind of defeat the point? Let's say my tree is /estc/results30000/ and estc/results60000/. If I put the first 30000 in results30000 and the next 30000 in results 60000 the estc/ directory will still have too many files. I am also confident on the free space – josh Aug 09 '11 at 16:49
  • 1
    I received the same error during a file write operation (download) in a Python script. The inodes as well as disk space were very much available. I had managed to run the Python script successfully on another machine and when I manually copied it to the first machine, the copy was successful. I don't understand how that worked if the issue was anything related to exceeding maximum file size, max directory/file count, or any other physical disk constraints. Any more information would be of so much help as I might encounter this issue again. – gvas Sep 09 '16 at 02:50
  • 2
    I have a similar error, using Python 3, Jupyter Notebooks, sklearn, RandomForestRegressor(n_jobs=-2). I believe it was because a function was using pickle a lot, but not sure about the real cause. Following [this](https://www.kaggle.com/getting-started/45288) answer I wrote ```%env JOBLIB_TEMP_FOLDER=/tmp``` in the Python notebook and everythin fine. I am not sure if it is useful here or if someone can expand. – Rafael Valero Aug 23 '18 at 15:18
  • This is an yeasrs old answer, but I'll try to ask regardless (don't wanna open a duplicate question). I got the same error during `np.save()` in a setup tha loops over a bunch o cases. The error ocurred after about 1.5k iterations and there were 150GB left in disc, so I don't know what to make out of it. – Puff Feb 25 '21 at 17:42
  • I want to add another potential cause of ENOSPC that I ran into. I work on managed Linux instances, and there is a quota with a hard limit on the 'home' directory. Conda uses ~/.conda for storing packages. Eventually, I was unable to use 'conda create ...', as it would give the 'no space left on device' message, but there was no indication of what was going wrong. Disk space, inodes, etc. all looked fine. I only figured it out when my ~/.bashrc got truncated when I tried 'conda init'. Clearing out ~/.conda packages fixed it. – Wesley R. Elsberry Mar 12 '21 at 16:15
  • so how do I fix this issue?? – Byusa Sep 12 '22 at 12:14
22

Try to delete the temp files

rm -r /tmp/
SapphireSun
  • 9,170
  • 11
  • 46
  • 59
shanky
  • 383
  • 2
  • 7
10

It turns out the best solution for me here was to just reformat the drive. Once reformatted all these problems were no longer problems.

Giacomo1968
  • 25,759
  • 11
  • 71
  • 103
josh
  • 1,544
  • 2
  • 16
  • 27
  • 5
    I had the same question. Would be nice if people left an explanation with their downvotes. – josh Feb 14 '17 at 16:19
  • 8
    The cause of the problem here seems to have been inodes / directory entries... (And it seems to have been vfat specific) That is not obvious in the question (without the comments) (and this answer mainly provides a workaround, which is not practical in many cases...) (You also did not specify whether it was formatted with vfat again, or a different filesystem...) – Gert van den Berg Oct 19 '17 at 10:36
  • 2
    You cannot always reformat. Reformating is always an obvious solution. Did you not need to keep the data on your device??? That is a reason to downvote. – georgesjeandenis Jan 26 '22 at 04:48
  • @josh Please explain how you "reformatted" the drive – DialFrost Aug 13 '22 at 04:04
8
  1. Show where memory is allocated sudo du -x -h / | sort -h | tail -40
  2. Delete from either your /tmp or /home/user_name/.cache folder if these are taking up a lot of memory. You can do this by running sudo rm -R /path/to/folder

Step 2 outlines fairly common folders to delete from (/tmp and /home/user_name/.cache). If you get back other results when running the first command showing you have lots of memory being used elsewhere, I advise being a bit more cautious when deleting from those locations.

Colonel_Old
  • 852
  • 9
  • 15
5

In my case, when I run df -i it shows me that my number of inodes are full and then I have to delete some of the small files or folder. Otherwise it will not allow us to create files or folders once inodes get full.

All you have to do is delete files or folder that has not taken up full space but is responsible for filling inodes.

ARKhan
  • 1,724
  • 22
  • 30
3

run "export TEMPDIR=/someDir" where some dir is a valid directory other than /tmp. Run this on prompt before running your python command. In my case it is "pip install rasa[spacy]" which was earlier failing.

The export command allows you to temporarily use the specified dir as temp dir.

Chandan
  • 39
  • 3
  • 5
    I think this should be TMPDIR, not TEMPDIR, per https://docs.python.org/3/library/tempfile.html#tempfile.mkstemp - also, apparently TEMP and TMP are checked as well. – Gord Stephen Nov 26 '19 at 00:25
0

I faced a similar issue. The above solutions for deleting the /tmp directory worked for me.

Instead of using the default /tmp location where the service account might not have full access (if following best practices and not using sudo to install Python packages), I moved the /tmp directory to the user's home directory, with TMPDIR environment setting honored by pip install --user ... command.

I faced the issue above of running out space, as mentioned in the answeres above most likely due to so many files/directories being created and not actually running out of volume storage. The solution that worked for me was to delete the /home/<some_domain>/$USER/tmp directory and recreate it every time my continuous deployment pipeline ran. rm -rf /tmp

H A
  • 1,251
  • 2
  • 24
  • 39
0

I ran into this problem when running tests. The Django app I was running was inside a docker container, so I had to log in to the container as a root, run rm -r /tmp/ and it fixed the issue.

0

I have the same problem, but found the root cause is "print too frequently" at last. On my code I have some "print(...)" logic which running in loop. When I comment those code, the "No space left on device" error disappeared. Perhaps it is a Python implementation problem. You may try this solution.

For more detail, sample descriptive code will look like following:

loop:
    do some logic 
    call "print" to check result

When your logic code running very fast, you will call "print" very frequently. Then sometimes "[Errno 28] No space left on device" error will appear.

I think this is an implementation limitation of Python "print" code, though I not read the code yet. My Python version is 3.9.7

Thanks for Community reply.

xxrlgame
  • 1
  • 1
  • 3
    Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Mar 05 '22 at 01:41