Excerpts from liubo's message of 2011-04-18 02:49:51 -0400:
> On 04/16/2011 03:32 AM, Josef Bacik wrote:
> > On 04/15/2011 03:24 PM, Christoph Hellwig wrote:
> >> Sorry, but this is too ugly to live. If the reason for this really is
> >> good enough we'll just need to push the filemap_write_and_wa
On 04/18/2011 02:49 AM, liubo wrote:
On 04/16/2011 03:32 AM, Josef Bacik wrote:
On 04/15/2011 03:24 PM, Christoph Hellwig wrote:
Sorry, but this is too ugly to live. If the reason for this really is
good enough we'll just need to push the filemap_write_and_wait_range
and i_mutex locking into e
On 04/16/2011 03:32 AM, Josef Bacik wrote:
> On 04/15/2011 03:24 PM, Christoph Hellwig wrote:
>> Sorry, but this is too ugly to live. If the reason for this really is
>> good enough we'll just need to push the filemap_write_and_wait_range
>> and i_mutex locking into every ->fsync instance.
>>
>
>
On Fri, Apr 15, 2011 at 03:34:57PM -0400, Chris Mason wrote:
> Excerpts from Christoph Hellwig's message of 2011-04-15 15:24:12 -0400:
> > Sorry, but this is too ugly to live. If the reason for this really is
> > good enough we'll just need to push the filemap_write_and_wait_range
> > and i_mutex
Excerpts from Christoph Hellwig's message of 2011-04-15 15:24:12 -0400:
> Sorry, but this is too ugly to live. If the reason for this really is
> good enough we'll just need to push the filemap_write_and_wait_range
> and i_mutex locking into every ->fsync instance.
>
Which part is too ugly to li
On 04/15/2011 03:24 PM, Christoph Hellwig wrote:
Sorry, but this is too ugly to live. If the reason for this really is
good enough we'll just need to push the filemap_write_and_wait_range
and i_mutex locking into every ->fsync instance.
So part of what makes small fsyncs slow in btrfs is all
Sorry, but this is too ugly to live. If the reason for this really is
good enough we'll just need to push the filemap_write_and_wait_range
and i_mutex locking into every ->fsync instance.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord.
Btrfs needs to be able to control how data is submitted in the case of fsync to
make it a little faster, and really we could get rid of holding the i_mutex
altogether as well. So introduce a ->fsync_nolock helper that pushes the
responsibility of locking the inode and doing the filemap_write_and_w
