>someone said:
> Sounds to me like you have an application which is opening files
> and holding them open even after they're deleted. The free space is not
> released until the file is closed. The fact that you found the file
> system "busy" when you went to unmount it, tends to confirm that. I'm
> not totally sure if fuser is going to pick up on just the files that
> it finds in the directory structure (missing the open but deleted inodes)
> or if it looks at the inodes that are being held open, the man page is
> not clear about that. Guess I should find that out, but I use lsof more
> than fuser. At least lsof distinctly mentions the appearance of such
> orphaned files, so I know it shows them up.
---Just tested lsof/fuser. VMware deletes an open file in /tmp that it uses for some purpose while it is up. An fuser on /tmp gives:
USER PID ACCESS COMMAND /tmp root 126 f.... cardmgr root 284 ..c.. xfstt root 303 f.... X law 652 f.... kfm root 1459 f...m vmware <-- root 3399 f...m vmware root 3400 f...m vmware root 3401 f...m vmware law 13309 ..c.. bash ----
Notice in particular process 1459. An ls -l of /proc/1459/fd/11 yields:
lrwx------ 1 root root 64 May 16 09:45 fd/11 -> /tmp/ram0 (deleted)
A lsof -p 1459|grep tmp yields:
vmware 1459 root 11u REG 3,6 142737408 398 /tmp/ram0 (deleted)
I.e. both lsof and fuser indicate /tmp usage (the deleted file is the only file vmware has open on /tmp). Note that the size is *big* (142M). A df of /tmp shows:
Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda6 520824 2304 492064 0% /tmp
Note that the 143 meg isn't accounted for :-(. Du -s /tmp yields:
2304 /tmp
A scan for 'hidden files' yields: # find . -name ".[^.]*" -exec du -s {} \;|grep -v "^0 " 4 ./.sax_dir 4 ./.X11-unix 4 ./.esd 4 ./.X0-lock 4 ./.font-unix 20 ./.XF86Setup1081 8 ./.XF86Setup1566 8 ./.XF86Setup1617
I.e. du and df both pick up hidden files (56K in all). Neither pick up the deleted file. I would expect 'du' not to pick up the file, however I would have expected 'df' (fstatfs) to give me an accurate count. :-(
None of this explains Sasi's situation, however (the above was on an unpatched 2.2.15 kernel).
-l
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:11 EST