Tag Info

Hot answers tagged

29

You can't create a link to it, but you can get it back. Let's do an experiment: $ echo blurfl >myfile.txt $ tail -f myfile.txt & $ rm myfile.txt myfile.txt is now gone, but the inode is kept alive by the tail command. To get your file back, first find the PID of the process keeping the inode: $ ps auxw | grep tail sunny 409 0.0 0.0 8532 ...


11

man mke2fs You will see a -N for number of inodes So you can spec it when you format a new partition. Not so helpful right now, huh? tune2fs, which tunes the filesystem, doesn't seem to have a way to add more inodes. But maybe ext3 or 4 does this, and someone else knows....? So now you have an option: backup, reformat partition, restore.


11

Don't expect this to run quickly... cd to a directory where you suspect there might be a subdirectory with lots of inodes. If this script takes a huge amount of time, you've likely found where in the filesystem to look. /var is a good start... Otherwise, if you change to the top directory in that filesystem and run this and wait for it to finish, you'll ...


10

To answer the original question, even though it is probably late for the questioner - yes, increasing EXT2/3 on LVM2 will also increase the inodes limit. Just had a partition of 1G size with 65k inodes limit. After lvextend -L+1G /dev/vg/var umount /var resize2fs /dev/vg/var mount /var ... my inodes limit is now 128k.


10

It sounds like you already understand a lot, so I won't go into excess detail. There's several methods to find the inode and you can usually cat and redirect STDOUT. You can use debugfs. Run this command within: ln <$INODE> FILENAME Make sure you have backups of the filesystem. You'll probably need to run a fsck afterwards. I tested this ...


10

Really you should not choose a "creative" solution if you have a simple, effective, and more correct way to do it. Just because the migration isn't easy to implement, the creative solution, in my experience, usually ends with a much bigger headache down the road and ending up having to do it the "right" way anyway. It sounds like you already know better ...


8

There is no default as such for ext4, it depends on the size of the device and the options chosen at creation. You can check the existing limits using tune2fs -l /path/to/device For example, root@xwing:~# tune2fs -l /dev/sda1 tune2fs 1.42 (29-Nov-2011) Filesystem volume name: <none> Last mounted on: / [lots of stuff snipped] Inode ...


7

Awesome enough would be if you could "undo" the delete by running some magic option to ln that would let you re-link to the inode number (recovered through lsof). This awesomeness was introduced to ln in v8.0 (GNU/coreutils) with the -L|--logical option which causes ln to dereference a /proc/<pid>/fd/<handle> first. So a simple ln -L ...


7

Here are the answers that are true for ext2/ext3/ext4. If they are true for other file systems depends on their implementation. user48838 answered this one correctly. More files consume more meta data. They are allocated in 4k chunks or in any other size defined at creation time of the file system Yes it is a feature/problem of the real file system In an ...


7

If you're using the NetApp as a NAS, i.e. using NAS protocols such as NFS, CIFS/SMB, http etc. then you don't get to choose the filesystem, it uses NetApp's WAFL file system, you can't change it. If you're using the NetApp to provide block-level sharing such as iSCSI/Fibre-Channel/FCoE then it's irrelevant that it's on a NetApp - you can assume it's on ...


6

the debugfs way as you saw doesn't really work and at best your file will be deleted automatically (due to the journal) after reboot and at worst you can trash your filesystem resulting to "reboot cycle of death". The Right Solution (TM) is to perform the undelete in the VFS level (which also has the added benefit of working with practically all current ...


6

I think by default current versions of mkfs.ext2/3/4 default to 256 byte inode size (see /etc/mke2fs.conf). This IIRC enables nanosecond timestamps with ext4, and as you say, more extended attributes fit within the inode. Such extended attributes are, for instance, ACL's, SELinux labels, some Samba specific labels. Bigger inodes of course waste a little bit ...


6

You can set the number of inodes available in a tmpfs with the nr_inodes mount option. To do this live, you can just run: mount -o remount,nr_inodes=<bignum> /tmp I suspect that setting this number very, very large will result in a lot of memory consumption, so be careful.


6

AFAIK, find searches the filesystem's directories. If that file was deleted but still existing because it's open (a common trick on unix), it won't be found by find. I haven't tried in Solaris, but here is a note about using lsof to identify such 'deleted but open' files, and recovering via a cat /proc/<procid>/fd/<fdid> > /tmp/xxxx Edit: ...


6

Some of the previous answers give you general ideas of what is going on, but let us find out how to do something about it. I know you're going to think this pedantic, but let's start with your filesystem type and discuss each as we've seen them under Linux. The fact that your question is tagged with Linux is important because other *nix file systems ...


6

You've identified the best approaches/fixes to the problem. There's no shortcut available to you at this point. The ext2/ext3 filesystems have a hard limit of 31998 links. Of course, the XFS filesystem is another nice solution for this... Can you provide more information on the application and reason for so many subdirectories?


6

Usually (ex: ext2, ext3, ext4, ufs), the number of inodes a file system can hold is set at creation time so no mount option can workaround it. Some filesystems like xfs have the ratio of space used by inodes a tunable so it can be increased at any time. Modern file systems like ZFS or btrfs have no hardcoded limitation on the number of files a file system ...


5

Grrr, commenting requires 50 rep. So this answer is actually a comment on chris's answer. Since the questioner probably doesn't care about all the directories, only the worst ones, then using sort is likely very expensive overkill. find . -type d | while read line do echo "$(ls "$line" | wc -l) $line" done | perl -a -ne'next unless ...


5

The file-system uses inodes to track file locations on disk. If you don't have any more inodes, you can't write more files to the file-system until there are more available. It is best to plan what will live on the file-system before formatting it as with many file-systems, you can choose the inode default size appropriate to the size of file that will ...


4

If the file is held open by another process then you can recover the file by using the inode number. find /path/to/check -inum 1023564 -exec cp {} recoveredfile \; If the file not held open by another process then your out of luck with using the inode.


4

The block increments that you are seeing is due to how the file system manages its storage of files and related file management information. In your described situation, that would appear to increments of 4K, so each "new"/"unique" entry into the file system will reserve 4K, whether the actual data size fills up the entire 4K. If the related data takes up ...


4

Server specifications are likely to be less of an issue than the file system you are using. Different file systems have different approaches to storing directory data. This will impact the scanning speed at various sizes. Another important consideration is the lifecycle of the files. If you have frequent addition and deletion of files you may want the ...


4

If you have a RAID array that has three failing drives, there is low probability of getting the raidset back into service. Sorry. I'm afriad to say your only alternative is to replace the failing disks, recreate the raidset, and then restore the information from your most recent backup set. You realize the btrfs is still relatively experimental and thus ...


4

what is this directory (/usr/local/nginx/client_body_temp/) for? The directory was used to save buffered temporary file from client request body. Normally the temporary file inside the directory was used to buffer request body that larger than client_body_buffer_size. And normally the file was removed after nginx has finished process the request. Other ...


3

Orphaned inodes are benign and perfectly normal whenever you have an unclean dismount. They are simply files that had been deleted, but were still open when the fs was remounted read only. They are not the cause, but merely a symptom. You need to check your kernel logs to see what the actual problem was that caused the read only remount. You also might ...


3

As a stopgap, mount a new filesystem, and cp/rm/ln-s some of your fs hierarchy there. Now you have a few spare inodes! You can't mv files between the two fses, so beware breaking things that need to do that, but for many apps this can be transparent. Then make a new fs, per Paul's advice, and migrate onto that.


3

If the inode count is your actual issue, you can increase the amount of available inodes for the tmpfs filesystem with the nr_inodes mount option. If you set nr_inodes=0 , then there will be unlimited inodes. All this information is in the tmpfs kernel documentation. See womble's answer for remount example. For boot, you will need to edit your fstab, or ...


3

This isn't a direct answer to your question, but searching for recently modified files with a small size using find might narrow down your search: find / -mmin -10 -size -20k


3

If the issue is one directory with too many files, here is a simple solution: # Let's find which partition is out of inodes: $ df -hi Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda3 2.4M 2.4M 0 100% / ... # Okay, now we know the mount point with no free inodes, # let's find a directory with too many files: $ ...



Only top voted, non community-wiki answers of a minimum length are eligible