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: <20100408143102.GE10879@redhat.com>
Date:	Thu, 8 Apr 2010 10:31:02 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Jeff Moyer <jmoyer@...hat.com>
Cc:	Jens Axboe <jens.axboe@...cle.com>,
	"Theodore Ts'o" <tytso@....edu>, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch,rfc v2] ext3/4: enhance fsync performance when using cfq

On Thu, Apr 08, 2010 at 10:25:50AM -0400, Jeff Moyer wrote:
> Vivek Goyal <vgoyal@...hat.com> writes:
> 
> > On Thu, Apr 08, 2010 at 10:03:24AM -0400, Jeff Moyer wrote:
> >> Which actually brings up the question of whether this needs some
> >> knowledge of whether the journal is on the same device as the file
> >> system!  In such a case, we need not yield.  I think I'll stick my head
> >> in the sand for this one.  ;-)
> >
> > Jeff even if journal is not on same device, what harm yielding could do?
> > Anyway there is no IO on that queue and we are idling. Only side affect is
> > that yielding process could lose a bit if after fsync it immediately submits
> > more IO. Because this process has yielded it slice, it is back in the queue
> > instead of doing more IO in the current slice immediately.
> 
> What happens if the journal is on a super fast device, and finishes up
> very quickly allowing our process to initiate more I/O within the idle
> window?
> 

You lose. :-) But at the same time if journalling devices is not fast
enough, and you if can't submit next IO in idling window, then you are 
unnecessarily keeping the disk idle and preventing others from making
progress.

Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ