Re: kernel work week of 3-Feb-2010 HEADS UP
--0015175884fecc133b047ed7f53a
Content-Type: text/plain; charset=ISO-8859-1
2010/2/5 Matthew Dillon <dillon@apollo.backplane.com>
>
> :Is the concern that people would be more inclined to remove an SSD than a
> :regular drive by mistake, or that splitting off the log could lead to an
> :"oops, I forgot that the log was separate" situation when changing out
> :drives? Or something else?
> :
> :It seems like an odd thing to worry about, to be honest. If you can't
> :trust users not to start removing important components from their
> :systems...
> :
> :MAgnus
>
> Well, true enough. I guess the real issue I have is that one
> is dedicated a piece of equipment to a really tiny piece of the
> filesystem. Though I can't deny the utility of having a fast fsync().
> If the storage system is big enough then, sure. If you're talking
> about going from one physical drive to two though it probably isn't
> worth the added complexity it just to get a fast fsync().
>
I probably don't understand well enough what it would mean if we have
the root volume and especially the UNDO log on a very fast SSD. Would the
only
thing that is improved be the fsync performance, or would normal write
operations also benefit a little from it (not the actual writes, but
because
writes can be queued and issued more optimal by the disk, not waiting
for the UNDO log to be synced to disk)?
While I am asking questions, here is another one:
When an ATA_SYNC (or _FLUSH?) command is issued to the disk, is this
global for all outstanding blocks to be written to disk, or is it possible
to
specify a logical block number range? For example, if we'd have two
partitions
on disk, a sync would then sync both partitions, wouldn't it?
Regards,
Michael
--0015175884fecc133b047ed7f53a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br><div class=3D"gmail_quote">2010/2/5 Matthew Dillon <span dir=3D"ltr=
"><<a href=3D"mailto:dillon@apollo.backplane.com">dillon@apollo.backplan=
e.com</a>></span><br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
:Is the concern that people would be more inclined to remove an SSD than a<=
br>
<div class=3D"im">:regular drive by mistake, or that splitting off the log =
could lead to an<br>
:"oops, I forgot that the log was separate" situation when changi=
ng out<br>
:drives? =A0Or something else?<br>
:<br>
:It seems like an odd thing to worry about, to be honest. =A0If you can'=
;t<br>
:trust users not to start removing important components from their<br>
:systems...<br>
:<br>
:MAgnus<br>
<br>
</div> =A0 =A0Well, true enough. =A0I guess the real issue I have is that o=
ne<br>
=A0 =A0is dedicated a piece of equipment to a really tiny piece of the<br>
=A0 =A0filesystem. =A0Though I can't deny the utility of having a fast=
fsync().<br>
=A0 =A0If the storage system is big enough then, sure. =A0If you're ta=
lking<br>
=A0 =A0about going from one physical drive to two though it probably isn&#=
39;t<br>
=A0 =A0worth the added complexity it just to get a fast fsync().<br></bloc=
kquote><div><br></div><div>I probably don't understand well enough what=
it would mean if we have</div><div>the root volume and especially the UNDO=
log on a very fast SSD. Would the only</div>
<div>thing that is improved be the fsync performance, or would normal write=
</div><div>operations also benefit a little from it (not the actual writes,=
but because=A0</div><div>writes can be queued and issued more optimal by t=
he disk, not waiting</div>
<div>for the UNDO log to be synced to disk)?</div><div><br></div><div>While=
I am asking questions, here is another one:</div><div>When an ATA_SYNC (or=
_FLUSH?) command is issued to the disk, is this=A0</div><div>global for=A0=
all outstanding blocks to be written to disk, or is it possible to</div>
<div>specify a logical block number range? For example, if we'd have tw=
o partitions</div><div>on disk, a sync would then sync both partitions, wou=
ldn't it?</div><div><br></div><div>Regards,</div><div><br></div><div>
=A0=A0Michael=A0</div><div><br></div><div><br></div></div>
--0015175884fecc133b047ed7f53a--
討論串 (同標題文章)
完整討論串 (本文為第 21 之 30 篇)：