On Sat, Feb 21, 2015 at 01:06:08AM +0900, Akira Hayakawa wrote:
> The size is configurable but typically 512KB (that's the default).
>
> Refer to bio payload sounds really dangerous but it may be possible
> in some tricky way. but at the moment I am not sure how the
> implementation would be.
>
>
On Sat, Feb 21, 2015 at 12:25:53AM +0900, Akira Hayakawa wrote:
> Yes.
How big are your log chunks? Presumably they're relatively small (eg,
256k). In which case you can optimise for the common case where you
have enough bios to hand to build your log chunk by just referencing
the bio payloads,
On Fri, Feb 20, 2015 at 05:44:01PM +0900, Akira Hayakawa wrote:
> I will wait for ack from dm maintainers.
Are you still copying the contents of every bio to your own memory
buffer before writing it to disk?
- Joe
___
devel mailing list
de...@linuxdrive
On Fri, Dec 12, 2014 at 09:42:15AM +0900, Akira Hayakawa wrote:
> The SSD-caching should be log-structured.
No argument there, and this is why I've supported you with
dm-writeboost over the last couple of years.
However, after looking at the current code, and using it I think it's
a long, long wa
On Thu, Oct 03, 2013 at 10:27:54PM +0900, Akira Hayakawa wrote:
> > dm-cache doesn't have this problem, if you overwrite the same piece of
> > data again and again, it goes to the cache device.
>
> It is not a bug but should/can be optimized.
>
> Below is the cache hit path for writes.
> writeb
On Thu, Sep 26, 2013 at 01:43:25PM +1000, Dave Chinner wrote:
> On Tue, Sep 24, 2013 at 09:20:50PM +0900, Akira Hayakawa wrote:
> > * Deferring ACK for barrier writes
> > Barrier flags such as REQ_FUA and REQ_FLUSH are handled lazily.
> > Immediately handling these bios badly slows down writeboost.
