fsync and ftruncate weirdness

[Greg Smith <gsmith@nc.rr.com>]

[-- Attachment #1: Type: text/plain, Size: 2484 bytes --]

Alan Cox suggested that I forward this message here and attach the
testcase.  For clarification, `hercules' is an ibm mainframe emulator
-- yes, I know how that sounds, but ac himself has been rumoured to
use it.  Warning, if you are able to recreate the error using the
testcase then you may have to reboot.  I have only recreated the
problem on ia32.

Symptom is *very* slow response time for ftruncate() after fsync()
and ftruncate() have already been issued previously for the file,
if the file is large (hundreds or thousands of megabytes).

Many thanks,

Greg Smith

Greg Smith wrote:
> Hi Alan.  I got your email address from the linux-vm list on Marist.
> I'm also a developer for hercules, mostly doing the compressed disk
> emulation, but also other stuff (eg the linux-390 i/o problem).
> 
> I've run into a problem and don't know where to turn with it,
> so maybe you can give me some advice.
> 
> In the next release of hercules (2.17) we will do a fsync every
> 5 seconds (by default) for an emulated disk image.  Code has been
> added to not write to space that has been freed since the last
> fsync.  If some catastrophic error occurs, then we should be able
> to recover the disk image up to at least the time of the last fsync.
> 
> The size of an emulated disk image changes over time.  When
> free space is moved by the garbage collector to the end of the file,
> we issue ftruncate to decrease the file size.  Since the fsync was
> added, I have noticed that a slower machine (piii650 768M)  will go
> into a loop in kernel space lasting *hours*.  Oh, the file in this
> circumstance is large, exceeding 600M.
> 
> Using `oprofile' (http://oprofile.sourceforge.net/index.php3), I
> have determined that all the cpu time is spent in mm/filemap.c
> routine truncate_list_pages which is called by truncate_inode_pages.
> The linux kernel is 2.4.18.  The linux system is responsive, but
> the hercules process is hosed.  The last system call by hercules
> is ftruncate.  I am using ext3 fs; I mean to test on ext2 but
> haven't gotten to it yet.
> 
> If I remove either the fsync or the ftruncate, then the loop does
> not occur.  As a workaround, I am only issuing ftruncate if there's
> at least a M to truncate, and then I close the file and open it
> again before doing it.  Ugly, but beats the alternative.
> 
> Attached is a program that I was able to recreate the problem
> on my slower machine (./ftest test 800).
> 
> Thanks for your time,
> 
> Greg Smith



[-- Attachment #2: ftest.c.gz --]
[-- Type: application/x-gzip, Size: 679 bytes --]