Bug 9911 - fsync blocks concurrent writes to file
Summary: fsync blocks concurrent writes to file
Status: CLOSED WILL_NOT_FIX
Alias: None
Product: File System
Classification: Unclassified
Component: ext3 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Andrew Morton
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-07 17:40 UTC by Larkin Lowrey
Modified: 2010-01-19 20:15 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.23.8
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Test case (3.23 KB, application/octet-stream)
2008-02-07 17:55 UTC, Larkin Lowrey
Details

Description Larkin Lowrey 2008-02-07 17:40:57 UTC
Latest working kernel version: none
Earliest failing kernel version: 2.6.18
Distribution: RHEL 4 & Fedora 8
Hardware Environment: Dual Xeon & dual-core Athlon
Software Environment: Java 1.5.0_14
Problem Description: Multiple threads append transactions to a single file. When fsyncs are issued, no writes complete until the fsync completes. This has the effect of yielding the same write rate regardless of how many threads are writing to the file. Solaris 10 does not exhibit this problem and scales well as additional threads are added.

I have confirmed this by running strace and witnessing that writes block until immediately after the fsync completes.

When using truss on Solaris I have witnessed multiple writes completing while an fsync was in progress.

Steps to reproduce:

Open a file for writing.
Launch multiple threads with each one writing data and followed by an fsync, but only if data has been written since the last fsync.


I have googled this issue substantially and have found no answers.
Comment 1 Larkin Lowrey 2008-02-07 17:55:13 UTC
Created attachment 14746 [details]
Test case

This test case java code performs linear writes, then fsyncs, to a single file. It starts with one thread then increments the thread count up to 10. It then displays the per thread and aggregate transaction rate.

This should show that the transaction rate does not scale when adding threads (for ext3) and allows you to see that writes are blocked by fsyncs by using strace.
Comment 2 Anonymous Emailer 2008-02-07 19:13:54 UTC
Reply-To: akpm@linux-foundation.org

On Thu,  7 Feb 2008 17:40:57 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=9911
> 
>            Summary: fsync blocks concurrent writes to file
>            Product: File System
>            Version: 2.5
>      KernelVersion: 2.6.23.8
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: ext3
>         AssignedTo: akpm@osdl.org
>         ReportedBy: llowrey@nuclearwinter.com
> 
> 
> Latest working kernel version: none
> Earliest failing kernel version: 2.6.18
> Distribution: RHEL 4 & Fedora 8
> Hardware Environment: Dual Xeon & dual-core Athlon
> Software Environment: Java 1.5.0_14
> Problem Description: Multiple threads append transactions to a single file.
> When fsyncs are issued, no writes complete until the fsync completes. This
> has
> the effect of yielding the same write rate regardless of how many threads are
> writing to the file. Solaris 10 does not exhibit this problem and scales well
> as additional threads are added.
> 
> I have confirmed this by running strace and witnessing that writes block
> until
> immediately after the fsync completes.
> 
> When using truss on Solaris I have witnessed multiple writes completing while
> an fsync was in progress.
> 
> Steps to reproduce:
> 
> Open a file for writing.
> Launch multiple threads with each one writing data and followed by an fsync,
> but only if data has been written since the last fsync.
> 
> 
> I have googled this issue substantially and have found no answers.
> 

I supposing teaching java about sync_file_range() would be all too hard.

Note You need to log in before you can comment on or make changes to this bug.