Hi Daniel,<br><br>Thanks for your comments, much appreciated !<br><br>I'm with you, it's a volume manager problem rather than a filesystem problem.<br>There is some nice things to do on the volume manager layer, like this heirarchical storage but also corrupted data autocorrection, and a modern IDA kernel level implementation (cleversafe like-but-better) and probably more. Dedup should also be a part of it (I'm not sure to see the full picture here). It would be so nice to see linux ahead in that area !<br>
<br>You really push my will to start coding again :)   (fear of the amount of work is the main break I must admit)<br><br>Regards,<br><br>Michael B.<br><br><div class="gmail_quote">On Thu, Mar 12, 2009 at 11:35 AM, Daniel Phillips <span dir="ltr"><<a href="mailto:phillips@phunq.net">phillips@phunq.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">On Thursday 12 March 2009, Michael Keulkeul wrote:<br>
> Hi all,<br>
><br>
> Would it be possible to have a dedicated device for fast syncronious<br>
> transactions, and latter flush to slower storage with tux3, or is this hard<br>
> because of the design ?<br>
> Sort-of copy the ZIL scheme of ZFS, and be able to recover all writes after<br>
> a failover or a power loss.<br>
><br>
> Thanks in advance for your answers !<br>
><br>
> Michael B.<br>
<br>
</div></div>Hi Michael,<br>
<br>
I expect Tux3 to be pretty fast for synchronous writes even without a<br>
scheme like ZIL.  But if it were to be done, I would think a generic<br>
virtual block device that implements a heirarchical cache would make<br>
more sense than doing something special in the filesystem.<br>
<br>
In general, I would like to view most of this "accelerate disk with<br>
a small amount of expensive persistent storage" ideas as logical<br>
volume manager problems.  Unsolved ones, to be sure, but no actual<br>
reason for that.<br>
<br>
As a volume manager solution, we could map part of the volume to fast<br>
disk and most of the volume to normal, slow disk.  Then we always<br>
allocate new writes into the fast disk area, and migrate those blocks<br>
off somewhere else later (yes, Tux3 will have block migration).  A<br>
good Master's thesis or two in there for someone.<br>
<br>
Regards,<br>
<font color="#888888"><br>
Daniel<br>
</font></blockquote></div><br>