On Tue, Oct 08 2013 at 6:37am -0400,
Akira Hayakawa ruby.w...@gmail.com wrote:
Christoph,
You can detect O_DIRECT writes by second guession a special combination
of REQ_ flags only used there, as cfg tries to treat it special:
#define WRITE_SYNC (WRITE | REQ_SYNC |
On Sat, Oct 05, 2013 at 04:51:16PM +0900, Akira Hayakawa wrote:
Dave,
That's where arbitrary delays in the storage stack below XFS cause
problems - if the first FUA log write is delayed, the next log
buffer will get filled, issued and delayed, and when we run out of
log buffers (there
Dave,
That's where arbitrary delays in the storage stack below XFS cause
problems - if the first FUA log write is delayed, the next log
buffer will get filled, issued and delayed, and when we run out of
log buffers (there are 8 maximum) the entire log subsystem will
stall, stopping *all* log
Hi,
Two major progress:
1) .ctr accepts segment size so .ctr now accepts 3 arguments: backing dev
cache dev segment size order.
2) fold the small files splitted that I suggested in the previous progress
report.
For 1)
I use zero length array to dynamically accept the segment size.
writeboost
On Tue, Sep 24, 2013 at 09:20:50PM +0900, Akira Hayakawa wrote:
Hi, Mike
I am now working on redesigning and implementation
of dm-writeboost.
Ok, I'm dropping your original patch, please resend when you have
something you want merged into drivers/staging/
thanks,
greg k-h
Hi, Mike
I have made another progress yesterday:
Splitting the monolithic source code into
meaningful pieces is done.
It will follow in the next mail.
Yes, please share your plan. Anything that can simplify the code layout
is best done earlier to simplfy code review.
Sorry, should have been
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.
It surveils the bios with these flags and forcefully flushes them
at
Hi, Mike
I am now working on redesigning and implementation
of dm-writeboost.
This is a progress report.
Please run
git clone https://github.com/akiradeveloper/dm-writeboost.git
to see full set of the code.
* 1. Current Status
writeboost in new design passed my test.
Documentations are
Mike,
We don't need to go through staging. If the dm-writeboost target is
designed well and provides a tangible benefit it doesn't need
wide-spread users as justification for going in. The users will come if
it is implemented well.
OK.
The benefit of introducing writeboost will be
Mike,
First, thank you for your commenting.
I was looking forward to your comments.
I suppose you are sensing some smell in my design.
You are worrying that dm-writeboost will not only confuse users
but also fall into worst situation of giving up backward-compatibility
after merging into tree.
Hi, Mike
There are two designs in my mind
regarding the formatting cache.
You said
administer the writeboost devices. There is no need for this. Just
have a normal DM target whose .ctr takes care of validation and
determines whether a device needs formatting, etc.
makes me wonder
On Tue, Sep 17 2013 at 8:41am -0400,
Akira Hayakawa ruby.w...@gmail.com wrote:
Mike,
First, thank you for your commenting.
I was looking forward to your comments.
I suppose you are sensing some smell in my design.
You are worrying that dm-writeboost will not only confuse users
but
On Mon, Sep 16, 2013 at 05:53:57PM -0400, Mike Snitzer wrote:
- variable names need to be a bit more verbose (arr = array)
struct array is a horrible name. :P Please don't use either arr
or array.
regards,
dan carpenter
___
devel mailing list
13 matches
Mail list logo
