| View previous topic :: View next topic |
| Author |
Message |
Nokai001
n00b
Joined: 25 Sep 2007
Posts: 28
|
 Posted: Tue Jun 02, 2009 6:22 am Post subject: No space left on devices ext3 problem |
 |
|
Hi.
I have a 4gb root partiton. I get every time "no space left on devices" Why?
df:
| Code: |
/dev/hdc3 3845120 2044700 1605096 57% /
udev 10240 144 10096 2% /dev
shm 110008 0 110008 0% /dev/shm
|
tune2fs:
| Code: |
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: afd5afb7-fd3e-4bc6-bd08-993b6ac8b69e
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 244320
Block count: 976626
Reserved block count: 48831
Free blocks: 450105
Free inodes: 6
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 238
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8144
Inode blocks per group: 509
Filesystem created: Mon Jun 1 21:18:56 2009
Last mount time: Tue Jun 2 09:32:27 2009
Last write time: Tue Jun 2 09:32:27 2009
Mount count: 5
Maximum mount count: 29
Last checked: Mon Jun 1 21:18:56 2009
Check interval: 15552000 (6 months)
Next check after: Sat Nov 28 20:18:56 2009
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 685471c0-2b8f-4a73-b7a6-335f862b59bd
Journal backup: inode blocks
|
I think the problem is:
Free inodes: 6
Inode count: 244320
Inode size: 256
Inodes per group: 8144
Inode blocks per group: 509
How can i fix this?
On my other systems:
tune2fs:
| Code: |
une2fs 1.41.4 (27-Jan-2009)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 6d874e42-089c-45a0-91a4-f29f45014002
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1835008
Block count: 3664828
Reserved block count: 183241
Free blocks: 524414
Free inodes: 1342054
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 894
Blocks per group: 32768
Fragments per group: 32768
[b]Inodes per group: 16384
Inode blocks per group: 512[/b]
Filesystem created: Sun Nov 18 17:21:49 2007
Last mount time: Tue Jun 2 09:42:41 2009
Last write time: Tue Jun 2 09:42:41 2009
Mount count: 27
Maximum mount count: 27
Last checked: Fri May 1 11:37:30 2009
Check interval: 15552000 (6 months)
Next check after: Wed Oct 28 10:37:30 2009
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
[b]Inode size: 128[/b]
Journal inode: 8
First orphan inode: 906147
Default directory hash: tea
Directory Hash Seed: d89ebdc7-17d5-4e72-8454-45c90dc02106
Journal backup: inode blocks
|
thx
Gerd |
|
| Back to top |
|
 |
BitJam
Advocate
Joined: 12 Aug 2003
Posts: 2508
Location: Silver City, NM
|
| Posted: Tue Jun 02, 2009 7:50 am Post subject: |
|
|
AFAICT you are SOL for increasing the number of inodes (but see below). Everything I've found related to increasing ext2/3 inodes says it can not be done. This page is recent and says the same thing.
The traditional approach would be to somehow backup your data and then re-create the filesystem with more inodes. Or backup your data and use a fs that does not have a fixed number of inodes (such as jfs or xfs).
If you have a large free partition available, you can boot via a liveCD and then use that partition for doing the backup. This is the best solution IMO.
If you don't want to backup and re-format then there are some little tricks you can play to limp along for a while. Since you can't increase the number of nodes the key thing is to reduce the number of files on your root filesystem. One trick is to create a filesystem on a single file. I don't know the exact mount command off-hand but you can create a file system on a file just like you would create a filesystem on a partition. It looks like this page has instructions.
First you need to clear out some files in order to give yourself room to work. Maybe you can clean out /tmp or maybe some log files under /var/log. If worse comes to worse you can delete /usr/portage/* but you should at least try tarring it up before deleting. Then follow the instruction in the link above to create a loop device at /usr/portage. The size of the file should probably be about 1 Gig if you are using ext2/3. With a smallblock xfs file system I'm able to store the current portage tree in 337 Meg. Of course you will need to leave some room for growth. This will fix your inode problem for a while: | Code: | $ ls /usr/portage/*/* | wc - l
107471 |
If you couldn't backup /usr/portage/* before deleting then it will get repopulated the next time you do an emerge --sync. Make sure that /usr/portage is empty before mounting the new filesystem for good because the files on your root partition will not free up inodes unless they are actually deleted and not just masked by another partition.
You've run into this problem because the Portage system is pretending that the filesystem is a database. It's not. But that's why you have literally thousands of tiny files under /usr/portage soaking up all your inodes. |
|
| Back to top |
|
|
|
Installing Gentoo
