Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Jul 2004 11:31:32 -0700
From:      John-Mark Gurney <gurney_j@resnet.uoregon.edu>
To:        Matthias Andree <ma@dt.e-technik.uni-dortmund.de>
Cc:        Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Subject:   Re: magic sysrq keys functionality
Message-ID:  <20040728183132.GR991@funkthat.com>
In-Reply-To: <m31xiw8nzo.fsf@merlin.emma.line.org>
References:  <1090718450.2020.4.camel@illusion.com> <200407251112.46183.doconnor@gsoft.com.au> <20040726175219.GA96815@green.homeunix.org> <m3hdrulbfk.fsf@merlin.emma.line.org> <20040726155712.R32601@pooker.samsco.org> <200407262220.i6QMKMT0098911@khavrinen.lcs.mit.edu> <m31xiw8nzo.fsf@merlin.emma.line.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Matthias Andree wrote this message on Wed, Jul 28, 2004 at 11:44 +0200:
> Makes me wonder about efficiency (write latency).
> 
> I admit I'm not familiar with how the buffers are scheduled in
> particular, if there are "write batches" or something.
> 
> If however softdep needs to wait for individual blocks, real tagged
> queueing (with ordered tags in the right places and such) might be
> faster because the drive can then decide for itself in which order the
> blocks are written to the disks fastest, without violating any of the
> ordering assumptions softupdates code relies on.

As another person said much more clearly...  Softdep really does
dependancy tracking...  As long as there are no outstanding writes
that it needs (like it can't write a data block till the block is
marked as in use, nor can it update the inode that the file uses that
data block, till the data is writen to disk) are still out standing,
it will submit the write request...  so, if two blocks are not related
and have no oustanding dependancies, they will be scheduled and written
in parallel...  and let the real tag queueing do it's work...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040728183132.GR991>