Re: IIs factible to implement full writes of strips to raid using NVRAM memory in LFS?

[Jose Luis Rodriguez Garcia <joseyluis%gmail.com@localhost>]

On Fri, Aug 19, 2016 at 5:27 PM, Thor Lancelot Simon
>
> Perhaps, but I bet it'd be easier to implement a generic pseudodisk
> device that used NVRAM (fast SSD, etc -- just another disk device really)
> to buffer *all* writes to a given size and feed them out in that-size
> chunks.  Or to add support for that to RAIDframe.
>
> For bonus points, do what the better "hardware" RAID cards do, and if
> the inbound writes are already chunk-size or larger, bypass them around
> the buffering (it implies extra copies and waits after all).
>
> That would help LFS and much more.  And you can do it without having
> to touch the LFS code.

Won't it be easier to add a layer that do these tasks in
the LFS code. It has the disadvantage that it would be used only by
LFS, but it seems more simple, and it is more easier to bypass in
cases that a full segment write is done, and add future optimizations.

It would be very useful for LFS if the physical segments are usually
full. Physical segments contain one ore more segments.

Can some confirm that LFS completes the physical segments in most of
the cases? It is that I understand reading the Margo paper.

It is more or less, the thing that I had in mind.

> However, there's stll the issue that this could effectively reorder
> reads around synchronous writes if you are not careful, particularly
> with the boot-time replay.  Ensuring that is right is probably the
> trickiest part by far.

Could you elaborate or put a example?

If the driver/layer is a write cache of the disk, the boot-time replay
must access to the driver/layer, and use the blocks in the NVRAM if
they exist, I don't see the role of reorder reads.

Jose Luis