![]() Source code archives and distribution files for older versions of programs are not automatically removed when a new version is emerged.Īs with distribution files, binary packages are not automatically removed. If the installation of a package with a big source tree (kernel sources) is interrupted, the sources are not deleted automatically. The following table provides description of file paths to consider for cleanup. This generally occurs from system upgrades. Over time large (or a large number of) unnecessary files accumulate in certain directories on the system. 2.3 Reducing the reserved blocks percentage.2.1 Removing system maintenance related files.1.3 Filesystem reserved blocks percentage.But - if it's only a log file - you can truncate it safetly. you can truncate it by command (for that if application read from this file - it can be dangerous to them. Lr-x- 1 undefine undefine 64 lut 1 00:06 4 -> anon_inode:inotifyĪs you see - 3 fd is deleted. Lr-x- 1 undefine undefine 64 lut 1 00:06 3 -> /home/undefine/x (deleted) Lrwx- 1 undefine undefine 64 lut 1 00:05 2 -> /dev/pts/30 Lrwx- 1 undefine undefine 64 lut 1 00:06 1 -> /dev/pts/30 Lrwx- 1 undefine undefine 64 lut 1 00:06 0 -> /dev/pts/30 If you know pid - look what files are open by this pid: as mentioned above - you can kill application, which open file.If you remove file - you only delete reference from disk, but - there is still reference from application. Reference can be on disk (link in any directory), and. Try to review if there is a process that does this a lot and consider how you use it, or just find more space.įiles are deleted from filesystem where is deleted any reference to this inode. In normal usage, you shouldn't think of that space as free, and this also shouldn't be very common at all - with the exception of temporary files that are unlinked on purpose, there shouldn't really be any files that you would consider being unused, but still open. This is also one of the reasons that applications should really close the files when they finish using them. It's not freed, it's being actively used. So, the answer is, while the processes have the files still opened, you shouldn't expect to get the space back. Flash plugin is especially fond of this method: all the downloaded video files are held open, but the filesystem doesn't show them. That's even used for tempfiles: some implementations create a file and immediately unlink it, so it's not visible in the filesystem, but the process that created it is using it normally. ![]() That's the only sensible choice: while the file is being used, it's not important if someone else can no longer access it: you are using it and until you close it, you still have control over it - you won't even notice the filename is gone or moved or whatever. ![]() The space is physically freed only if there are no links left (therefore, it's impossible to get to it). ![]() Each file records the number of links to it: the links can be either the filename (plural, if there are multiple hard links to the same file), and also every time a file is opened, the process actually holds the "link" to the same space. On unices, filenames are just pointers (inodes) that point to the memory where the file resides (which can be a hard drive or even a RAM-backed filesystem).
0 Comments
Leave a Reply. |