<?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: bdf outputs discrepancy disk usage in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/bdf-outputs-discrepancy-disk-usage/m-p/2561541#M918677</link>
    <description>Thank you all,&lt;BR /&gt;&lt;BR /&gt;I used &lt;BR /&gt;cat /dev/null &amp;gt; filename&lt;BR /&gt;rm filename&lt;BR /&gt;to delete the file. Don't know why still have the problem.&lt;BR /&gt;&lt;BR /&gt;George</description>
    <pubDate>Fri, 03 Aug 2001 21:38:05 GMT</pubDate>
    <dc:creator>George Liu_2</dc:creator>
    <dc:date>2001-08-03T21:38:05Z</dc:date>
    <item>
      <title>bdf outputs discrepancy disk usage</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/bdf-outputs-discrepancy-disk-usage/m-p/2561538#M918674</link>
      <description>&lt;BR /&gt;                               the output of bdf showed the following: &lt;BR /&gt;                               /dev/vg02/lvol1 4007201 3606487 0 100% /data &lt;BR /&gt;&lt;BR /&gt;                               the disk was not reclaimed after i deleted a big file and sync. Any idea?</description>
      <pubDate>Fri, 03 Aug 2001 20:57:46 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/bdf-outputs-discrepancy-disk-usage/m-p/2561538#M918674</guid>
      <dc:creator>George Liu_2</dc:creator>
      <dc:date>2001-08-03T20:57:46Z</dc:date>
    </item>
    <item>
      <title>Re: bdf outputs discrepancy disk usage</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/bdf-outputs-discrepancy-disk-usage/m-p/2561539#M918675</link>
      <description>Hi George,&lt;BR /&gt;&lt;BR /&gt;You will most likely find that the process &lt;BR /&gt;that belonged to the large file that you&lt;BR /&gt;removed is still running. You need to&lt;BR /&gt;identify this process and kill it. You &lt;BR /&gt;could try 'fuser /dev/vg02/lvol1' and try&lt;BR /&gt;to trace the offender. If you have 'lsof'&lt;BR /&gt;this will also help by using 'lsof -i'&lt;BR /&gt;&lt;BR /&gt;HTH&lt;BR /&gt;-Michael</description>
      <pubDate>Fri, 03 Aug 2001 21:20:24 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/bdf-outputs-discrepancy-disk-usage/m-p/2561539#M918675</guid>
      <dc:creator>Michael Tully</dc:creator>
      <dc:date>2001-08-03T21:20:24Z</dc:date>
    </item>
    <item>
      <title>Re: bdf outputs discrepancy disk usage</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/bdf-outputs-discrepancy-disk-usage/m-p/2561540#M918676</link>
      <description>HI George:&lt;BR /&gt;&lt;BR /&gt;You have to understand how rm and the underlying system call unlink() works. rm (unlink) remove the file's directory entry and reduces the link count by one. If the link count is zero (no other links to this file (inode)) AND no process has the file open then and only then are the filesystem blocks deallocated. In fact, one of the standard idioms in using temp files is to create a file&lt;BR /&gt;(e.g. /var/tmp/xx3456.tmp), open the file, unlink (rm) the file, but don't close it. The process can then read from and write to this file to it's heart's content but there is no directory entry for it. Only when the file is closed (or the process exits) is the space reclaimed.&lt;BR /&gt;&lt;BR /&gt;You need to user fuser or lsof to find the process that has this file open and kill it. The space will then reappear.&lt;BR /&gt;&lt;BR /&gt;Clay</description>
      <pubDate>Fri, 03 Aug 2001 21:27:56 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/bdf-outputs-discrepancy-disk-usage/m-p/2561540#M918676</guid>
      <dc:creator>A. Clay Stephenson</dc:creator>
      <dc:date>2001-08-03T21:27:56Z</dc:date>
    </item>
    <item>
      <title>Re: bdf outputs discrepancy disk usage</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/bdf-outputs-discrepancy-disk-usage/m-p/2561541#M918677</link>
      <description>Thank you all,&lt;BR /&gt;&lt;BR /&gt;I used &lt;BR /&gt;cat /dev/null &amp;gt; filename&lt;BR /&gt;rm filename&lt;BR /&gt;to delete the file. Don't know why still have the problem.&lt;BR /&gt;&lt;BR /&gt;George</description>
      <pubDate>Fri, 03 Aug 2001 21:38:05 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/bdf-outputs-discrepancy-disk-usage/m-p/2561541#M918677</guid>
      <dc:creator>George Liu_2</dc:creator>
      <dc:date>2001-08-03T21:38:05Z</dc:date>
    </item>
    <item>
      <title>Re: bdf outputs discrepancy disk usage</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/bdf-outputs-discrepancy-disk-usage/m-p/2561542#M918678</link>
      <description>Hi George:&lt;BR /&gt;&lt;BR /&gt;If you created the file with /dev/null then your file should have been 0 bytes longs.&lt;BR /&gt;That is not your problem. You need to run fuser /data or much better lsof /data if you have lsof installed on your system. That will show you the process that is really using the space. You can download lsof from one of the HP-UX Porting Centers; it is really one of those utilities no UNIX box should be without.&lt;BR /&gt;&lt;BR /&gt;Clay&lt;BR /&gt;</description>
      <pubDate>Fri, 03 Aug 2001 22:15:52 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/bdf-outputs-discrepancy-disk-usage/m-p/2561542#M918678</guid>
      <dc:creator>A. Clay Stephenson</dc:creator>
      <dc:date>2001-08-03T22:15:52Z</dc:date>
    </item>
  </channel>
</rss>

