linux-kernel - Re: [RFC PATCH v2 15/21] loop: use aio to perform io on the underlying file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F919AA5.2030402@oracle.com>
Date:	Fri, 20 Apr 2012 12:19:33 -0500
From:	Dave Kleikamp <dave.kleikamp@...cle.com>
To:	"Maxim V. Patlasov" <mpatlasov@...allels.com>
CC:	Zach Brown <zab@...bo.net>, Jeff Moyer <jmoyer@...hat.com>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 15/21] loop: use aio to perform io on the underlying
 file

On 04/20/2012 11:14 AM, Maxim V. Patlasov wrote:
> On 04/20/2012 07:57 PM, Dave Kleikamp wrote:
>>> So yeah, I'd agree that the loop code should be reworked a bit so that
>>> both the filebacked and aio methods call vfs_sync() when they see
>>> REQ_FLUSH.
>> It's an easy fix. I don't anticipate that it will hurt performance too
>> badly.
> 
> Two questions:
> 
> 1. Could we use fdatasync there? (otherwise it can hurt performance very
> badly)

I don't see why not.

> 2. vfs_sync() is synchronous. loop_thread() will be blocked till it's
> completed. Would it be better to perform vfs_sync in another thread (to
> allow other bio-s in loop queue proceed)? Also, if there are more than
> one REQ_FLUSH bio in lo->lo_bio_list, we could call vfs_sync() only
> once. Make sense?

If more than one REQ_FLUSH bio is in the list, they should be performed
in order. We must call vfs_fsync() between each of them to guarantee that.

A less complex tradeoff would be to move the vfs_fsync() call to
loop_make_request() so it is called in the context of the thread making
the request. That would make those threads requesting ordered IO to pay
the price while others would be able to proceed.

This is something I can re-visit. I don't want to hold up progress on
the patchset for something that can be improved later.

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