[Top] [All Lists]

Re: hole punching performance

To: "Bradley C. Kuszmaul" <kuszmaul@xxxxxxxxx>
Subject: Re: hole punching performance
From: Florian Weimer <fw@xxxxxxxxxxxxx>
Date: Sun, 13 Jan 2013 10:26:13 +0100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <CAKSyJXf66H2U-BF-aYnSr2fF24_6LJw6swOx1RhUc_3Eqayaiw@xxxxxxxxxxxxxx> (Bradley C. Kuszmaul's message of "Wed, 2 Jan 2013 16:51:07 -0500")
References: <CAKSyJXf66H2U-BF-aYnSr2fF24_6LJw6swOx1RhUc_3Eqayaiw@xxxxxxxxxxxxxx>
* Bradley C. Kuszmaul:

> The question I have:  What will happen to the performance of other
> threads doing read() and write() operations?  Will hole-punching slow
> down the other read() and write() operations running in other threads?

Assuming that hole-punching creates extents (not sure if it does, you
can check with filefrag or other tools), you might experience a
slowdown during open(), when the entire list of extents is read from

I once was a heavy Berkeley DB user and had files with dozens of
gigabytes containing hundreds of thousands of extents, and open()
times in the order of minutes were not unusual with a cold cache and
other concurrent read activities from the same RAID device.  But these
files grew over time—perhaps hole punching results in better locality
of the extent data, so that reading it doesn't take so much time in
your case.

<Prev in Thread] Current Thread [Next in Thread>