I think that an fs full situation may occur in your case, have you tried a sleep after the rm? My systems behaves the same, and frequent df displays after the rm of a large file show an increaing amount of freespace.
Jan Jaeger >From: "Ferguson, Neale" <[EMAIL PROTECTED]> >Reply-To: Linux on 390 Port <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Strange fs behavior >Date: Wed, 11 Sep 2002 08:14:25 -0400 > >-----Original Message----- >Neale, >I do not quite understand what you are saying, >when a look at the rexx code i see a loop using various block sizes which: >1) writes to a file (with sufficient real storage, you will write to cache >only) > > In this instance the devices I'm using greatly exceed real memory. > >2) sleep for 2 seconds (what happens here? is there an update type sync >task >running which mignt take control?) > > I put in a sleep before (and after in a later version) to see if that >allowed things to settle down. However, I still get full reports. > >3) rm of the file (iirc rm 'syncs' the inode & bam blocks asyncronously) >4) sync (which should not do much as the cache has been invalidated) > >Do you mean to say that you get an fs full after removing the file (ie end >round though the loop)? > > > Yes, I get a full condition reported after the remove and dd tries to >write its 1st record. > >Note there's a typo in the exec. It should be: count = (10750000 * (4096 / >bs.I_bs)) % 1
