On Wed, Apr 5, 2017 at 12:27 PM, NeilBrown wrote:
> On Tue, Apr 04 2017, Christoph Hellwig wrote:
>
>> Looks fine,
>>
>> Reviewed-by: Christoph Hellwig
>>
>> But if you actually care about performance in any way I'd suggest
>> to use the loop device in direct I/O mode..
>
> The losetup on my test
On Tue, Apr 04 2017, Ming Lei wrote:
> On Mon, Apr 3, 2017 at 9:18 AM, NeilBrown wrote:
>>
>> When a filesystem is mounted from a loop device, writes are
>> throttled by balance_dirty_pages() twice: once when writing
>> to the filesystem and once when the loop_handle_cmd() writes
>> to the backin
On Tue, Apr 04 2017, Christoph Hellwig wrote:
> Looks fine,
>
> Reviewed-by: Christoph Hellwig
>
> But if you actually care about performance in any way I'd suggest
> to use the loop device in direct I/O mode..
The losetup on my test VM is too old to support that :-(
I guess it might be time to
On Mon, Apr 3, 2017 at 9:18 AM, NeilBrown wrote:
>
> When a filesystem is mounted from a loop device, writes are
> throttled by balance_dirty_pages() twice: once when writing
> to the filesystem and once when the loop_handle_cmd() writes
> to the backing file. This double-throttling can trigger
>
On Mon 03-04-17 11:18:51, NeilBrown wrote:
>
> When a filesystem is mounted from a loop device, writes are
> throttled by balance_dirty_pages() twice: once when writing
> to the filesystem and once when the loop_handle_cmd() writes
> to the backing file. This double-throttling can trigger
> posit
Looks fine,
Reviewed-by: Christoph Hellwig
But if you actually care about performance in any way I'd suggest
to use the loop device in direct I/O mode..
When a filesystem is mounted from a loop device, writes are
throttled by balance_dirty_pages() twice: once when writing
to the filesystem and once when the loop_handle_cmd() writes
to the backing file. This double-throttling can trigger
positive feedback loops that create significant delays. The
7 matches
Mail list logo