Re: kernel work week of 3-Feb-2010 HEADS UP
--00032555bd3e5a45d1047ed00871
Content-Type: text/plain; charset=ISO-8859-1
2010/2/5 Matthew Dillon <dillon@apollo.backplane.com>
>
> :...but you are leaving some room for also using it as a write cache later,
> :right? Whether it's some special hook for HAMMER's un/redo log, or
> :something completely filesystem agnostic, it seems it could be a huge
> :benefit to some applications. (like databases?)
> :
> :Just thinking out loud: if you have some resident-like way of "locking"
> :data on the SSD, that might be an interesting way to get something similar
> :to ReadyBoost. (That would perhaps make for a neat GSoC project?)
> :
> :MAgnus
>
> Yes, it's theoretically possible by creating a small partition
> on the SSD (separate from the swap partition) and assigning
> all of HAMMER's UNDO FIFO disk blocks to it. That would make
> fsync() considerably faster (65uS instead of 4-10ms). It's
> not on my personal TODO list though.
>
Btw, that should be already possible using multiple HAMMER volumes.
The SSD partition should be made the root volume. It can be very
small, so that only the UNDO log fits on it (maybe a GB?), the second volume
would then be the regular hard disk. Maybe we'd need to give newfs_hammer
a specific option so that it treats all space of the first volume as UNDO
and
uses the second volume for storage.
I think I can implement that. Matt, do you think the option to newfs_hammer
is
a good idea?
Regards,
Michael
--00032555bd3e5a45d1047ed00871
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>
:...but you are leaving some room for also using it as a write cache later,=
<br>
<div class=3D"im">:right? =A0Whether it's some special hook for HAMMER&=
#39;s un/redo log, or<br>
:something completely filesystem agnostic, it seems it could be a huge<br>
:benefit to some applications. (like databases?)<br>
:<br>
:Just thinking out loud: if you have some resident-like way of "lockin=
g"<br>
:data on the SSD, that might be an interesting way to get something similar=
<br>
:to ReadyBoost. =A0(That would perhaps make for a neat GSoC project?)<br>
:<br>
:MAgnus<br>
<br>
</div> =A0 =A0Yes, it's theoretically possible by creating a small part=
ition<br>
=A0 =A0on the SSD (separate from the swap partition) and assigning<br>
=A0 =A0all of HAMMER's UNDO FIFO disk blocks to it. =A0That would make=
<br>
=A0 =A0fsync() considerably faster (65uS instead of 4-10ms). =A0It's<b=
r>
=A0 =A0not on my personal TODO list though.<br></blockquote><div><br></div=
><div>Btw, that should be already possible using multiple HAMMER volumes.=
=A0</div><div>The SSD partition should be made the root volume. It can be v=
ery=A0</div>
<div>small, so that only the UNDO log fits on it (maybe a GB?), the second =
volume</div><div>would then be the regular hard disk. Maybe we'd need t=
o give newfs_hammer</div><div>a specific option so that it treats all space=
of the first volume as UNDO and</div>
<div>uses the second volume for storage.=A0</div><div><br></div><div>I thin=
k I can implement that. Matt, do you think the option to newfs_hammer is</d=
iv><div>a good idea?</div><div><br></div><div>Regards,</div><div><br></div>
<div>=A0=A0Michael</div><div><br></div></div><br>
--00032555bd3e5a45d1047ed00871--
討論串 (同標題文章)
完整討論串 (本文為第 14 之 30 篇)：