<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: filesystem full in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644427#M44546</link>
    <description>Rusty,&lt;BR /&gt;&lt;BR /&gt;It looks like someone removed sone files that were open.&lt;BR /&gt;&lt;BR /&gt;Basically, a file has 2 parts, the inode and the data.  When an open file is removed, the inode is removed but the space is not claimed backup on the filesystem until the process that had the file open has ended or been killed.&lt;BR /&gt;&lt;BR /&gt;The fuser command is useful if you are the root user but as this happenned in /home, it is possible that the offending files and processes were not owned by root.&lt;BR /&gt;&lt;BR /&gt;I would advise non-root users to do the following to check if a file that they wish to remove is not being written to:&lt;BR /&gt;&lt;BR /&gt;cp /dev/null filename&lt;BR /&gt;ll filename&lt;BR /&gt;&lt;BR /&gt;If the file starts to grow, it is still being written to.&lt;BR /&gt;&lt;BR /&gt;Cheers,&lt;BR /&gt;&lt;BR /&gt;Joseph</description>
    <pubDate>Tue, 15 Jan 2002 16:48:38 GMT</pubDate>
    <dc:creator>Joseph A Benaiah_1</dc:creator>
    <dc:date>2002-01-15T16:48:38Z</dc:date>
    <item>
      <title>filesystem full</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644419#M44538</link>
      <description>I'm seeing some strange behavior on an L-class server running 11.0&lt;BR /&gt;&lt;BR /&gt; I got a report that the /home filesystem was full.  I ran a bdf and indeed it reported that the filesystem was 100% full.  I then ran a du -k on /home and much to my surprise, it report I was using just over 12,000 K on this 1GB filesystem.&lt;BR /&gt;&lt;BR /&gt;   I ran a fuser -c and there were about 20 processes listed.  I then ran a fuser -ck to kill the processes.&lt;BR /&gt;&lt;BR /&gt;I again ran a bdf and ,again, much to my surprise, it listed /home as using 1%.  &lt;BR /&gt;&lt;BR /&gt;Any Ideas what is going on?&lt;BR /&gt;&lt;BR /&gt;TIA&lt;BR /&gt;&lt;BR /&gt;Rusty</description>
      <pubDate>Mon, 14 Jan 2002 16:15:24 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644419#M44538</guid>
      <dc:creator>Rusty Sapper</dc:creator>
      <dc:date>2002-01-14T16:15:24Z</dc:date>
    </item>
    <item>
      <title>Re: filesystem full</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644420#M44539</link>
      <description>It looks like there was a process that had an open file.  If a process is writing to a file, but has not closed it yet, it will be using blocks of disk space, but the inodes have not been updated, so an ls, or du may not show the file even though the space is being used.  When you killed the process, the file was not longer open and sinced it was never closed (inodes writen), the file was not saved so the disk space was freed up</description>
      <pubDate>Mon, 14 Jan 2002 16:18:51 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644420#M44539</guid>
      <dc:creator>Jeff Machols</dc:creator>
      <dc:date>2002-01-14T16:18:51Z</dc:date>
    </item>
    <item>
      <title>Re: filesystem full</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644421#M44540</link>
      <description>Hi Rusty:&lt;BR /&gt;&lt;BR /&gt;This is what is actually happening. I'll do it in C but it applies in to any process/language.&lt;BR /&gt;&lt;BR /&gt;1) Create a file &lt;BR /&gt;fdes = open("/home/myfile",O_RDWR | O_CREAT,0600);&lt;BR /&gt;2)unlink("/home/myfile");&lt;BR /&gt;3) Then do all the i/o you like.&lt;BR /&gt;4) Finally close(fdes).&lt;BR /&gt;&lt;BR /&gt;Until the file is closed, the file can be used by this process eventhough it has been unlinked (rm'ed). The file continues to occupy space in the filesystem until all processes which have the file open, close it.&lt;BR /&gt;&lt;BR /&gt;This is a standard idiom to use a temp file and in fact there a library function which does just this.&lt;BR /&gt;&lt;BR /&gt;Re\gards, Clay</description>
      <pubDate>Mon, 14 Jan 2002 16:21:55 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644421#M44540</guid>
      <dc:creator>A. Clay Stephenson</dc:creator>
      <dc:date>2002-01-14T16:21:55Z</dc:date>
    </item>
    <item>
      <title>Re: filesystem full</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644422#M44541</link>
      <description>Rusty,&lt;BR /&gt;&lt;BR /&gt;You will also see this when a user has opened a file for writing, then it is deleted, but because the file is still open, the file space isn't released back to the system.&lt;BR /&gt;&lt;BR /&gt;If you don't already have "lsof", I'd suggest getting it:&lt;BR /&gt;&lt;BR /&gt;&lt;A href="http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/lsof-4.55/" target="_blank"&gt;http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/lsof-4.55/&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;live free or die&lt;BR /&gt;harry</description>
      <pubDate>Mon, 14 Jan 2002 16:21:57 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644422#M44541</guid>
      <dc:creator>harry d brown jr</dc:creator>
      <dc:date>2002-01-14T16:21:57Z</dc:date>
    </item>
    <item>
      <title>Re: filesystem full</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644423#M44542</link>
      <description>Hi,&lt;BR /&gt;Sometimes described behaviour happends. It is caused by processes (especially zombie)holding  filesystem. Then bdf cannot estimate properly the filesystem utilization. Sometimes after removing a hudge amount od data from  filesystem similar bahaviour can occure (befor LVM update info).&lt;BR /&gt;Later,</description>
      <pubDate>Mon, 14 Jan 2002 16:22:00 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644423#M44542</guid>
      <dc:creator>Marcin Wicinski</dc:creator>
      <dc:date>2002-01-14T16:22:00Z</dc:date>
    </item>
    <item>
      <title>Re: filesystem full</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644424#M44543</link>
      <description>I agrre with Jeff</description>
      <pubDate>Mon, 14 Jan 2002 16:22:30 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644424#M44543</guid>
      <dc:creator>Wim Rombauts</dc:creator>
      <dc:date>2002-01-14T16:22:30Z</dc:date>
    </item>
    <item>
      <title>Re: filesystem full</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644425#M44544</link>
      <description>Hi Rusty,&lt;BR /&gt;&lt;BR /&gt;This often happens when a log file is removed while another process has it open.  First time I saw it was when /var/adm/syslog/syslog.log was deleted without stopping syslogd.  The system knows the space was allocated and a process has it opened.  du is simply doing math based on the inodes it finds and there is none for the deleted file.&lt;BR /&gt;&lt;BR /&gt;Darrell</description>
      <pubDate>Mon, 14 Jan 2002 16:28:51 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644425#M44544</guid>
      <dc:creator>Darrell Allen</dc:creator>
      <dc:date>2002-01-14T16:28:51Z</dc:date>
    </item>
    <item>
      <title>Re: filesystem full</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644426#M44545</link>
      <description>Hi, &lt;BR /&gt;&lt;BR /&gt;bdf sometimes shows incorrect informations about fs usage. Try umounting /home and mount it again.  Try running also fuser for there might might be some proceses keeping your /home. Also,  try to checking on the permission of your filesystem.&lt;BR /&gt;&lt;BR /&gt;Jose</description>
      <pubDate>Mon, 14 Jan 2002 16:33:52 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644426#M44545</guid>
      <dc:creator>Kurtkarl</dc:creator>
      <dc:date>2002-01-14T16:33:52Z</dc:date>
    </item>
    <item>
      <title>Re: filesystem full</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644427#M44546</link>
      <description>Rusty,&lt;BR /&gt;&lt;BR /&gt;It looks like someone removed sone files that were open.&lt;BR /&gt;&lt;BR /&gt;Basically, a file has 2 parts, the inode and the data.  When an open file is removed, the inode is removed but the space is not claimed backup on the filesystem until the process that had the file open has ended or been killed.&lt;BR /&gt;&lt;BR /&gt;The fuser command is useful if you are the root user but as this happenned in /home, it is possible that the offending files and processes were not owned by root.&lt;BR /&gt;&lt;BR /&gt;I would advise non-root users to do the following to check if a file that they wish to remove is not being written to:&lt;BR /&gt;&lt;BR /&gt;cp /dev/null filename&lt;BR /&gt;ll filename&lt;BR /&gt;&lt;BR /&gt;If the file starts to grow, it is still being written to.&lt;BR /&gt;&lt;BR /&gt;Cheers,&lt;BR /&gt;&lt;BR /&gt;Joseph</description>
      <pubDate>Tue, 15 Jan 2002 16:48:38 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/filesystem-full/m-p/2644427#M44546</guid>
      <dc:creator>Joseph A Benaiah_1</dc:creator>
      <dc:date>2002-01-15T16:48:38Z</dc:date>
    </item>
  </channel>
</rss>

