fsync and ftruncate weirdness

Greg Smith (gsmith@nc.rr.com)
Thu, 11 Jul 2002 20:22:50 -0400


This is a multi-part message in MIME format.
--------------020300020106000507050609
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------020300020106000507050609
Content-Type: application/x-gzip;
name="ftest.c.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="ftest.c.gz"

H4sICIj0LT0AA2Z0ZXN0LmMAdVNtS+NAEP6c/IqhouzW2KYt7R2kCqL9cJwv0CoKXglpstHl
kk3Jbk7U+t9vZhPti7iQ7OaZmWdmnp102yCzrNKmjIyAZVksMpFDpaV6hFS/qJhxOIDUlJWK
0YNxF+zqdFMjtIFUZkJFuQAtXwUAs5vUoKp8IUq45Ojb7rp7UsVZlQgYa5NkctF5OtnEXnTX
vCyF/gprE5ltNI2VyXYcTSKLbahSEtFtzMhcEOLuJSKVSkAZqaTImeLAmFSGM4bndq/jt8nC
OO+y6enVeXh5ek8o59x10Q/ySCqgCIjKx9iD+CkqoY3nfw9z7r45ZJFemnj6NXAd1LaKDVAn
+EKA6gjxjOp6qnhGxBIsqvRhNBwORvPAdR2ZAiN2GMMAVitU9hWOITKFZDZRf845jI/B567j
lMJUpYKjHkWmCToWS6Fqx97cuw6n53fT1XV4Np2c3uA+uT+78Gbhr+ntbLrC/Q53HtRJMXyM
rPCGvEtRlkXJWsTWIofNTM47JUOzxHx+ABLjbP14PDyksqgjOUdrI3R/OOLB16BBH9qAUn2E
PZcSJw3lgwNiaIIH/R+jn3zuQX0gHlIQaVBDfJOq7Or24oLqXJZ4Bylr0XjCx0zuJ5coIOzr
P6qFV+PFNuQAwznFYFWwVVZQi5DSzdXlaGNFyLQQf8FCrEjT0PCmRm062oSU76iu0oPZZPI7
nE1ubCDp27j2OLWKekaJJcJO1605jsAcZF9rseNAVNT4ybEdJDiEYV3uuneL09rXrd1mqS0y
I3X9WZsJq78/WT5+/U0W69bQfNptlWsF4Gij2m/p4yJfZgKjm2vZSQDfLJwUonnHp9KZEEvW
833fUq/7tCPqxFmhRdNmM71+4L67/wHlHwM/+gQAAA==
--------------020300020106000507050609--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/