Mike,
I am happy to see that
guys from filesystem to the block subsystem
have been discussing how to handle barriers in each layer
almost independently.
>> Merging the barriers and replacing it with a single FLUSH
>> by accepting a lot of writes
>> is the reason for deferring barriers in
Dave,
> i.e. there's no point justifying a behaviour with "we could do this
> in future so lets ignore the impact on current users"...
Sure, I am happy if we find a solution that
is good for both of us or filesystem and block in other word.
> e.g. what happens if a user has a mixed workload -
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 | REQ_NOIDLE)
> #define WRITE_ODIRECT (WRITE | REQ_SYNC)
>
> the lack of
On Tue, Oct 08, 2013 at 10:43:07AM +1100, Dave Chinner wrote:
> > Maybe, writeboost should disable deferring barriers
> > if barrier_deadline_ms parameter is especially 0.
> > Linux kernel's layered architecture is obviously not always perfect
> > so there are similar cases in other boundaries
> >
On Tue, Oct 08, 2013 at 10:43:07AM +1100, Dave Chinner wrote:
Maybe, writeboost should disable deferring barriers
if barrier_deadline_ms parameter is especially 0.
Linux kernel's layered architecture is obviously not always perfect
so there are similar cases in other boundaries
such as
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 | REQ_NOIDLE)
#define WRITE_ODIRECT (WRITE | REQ_SYNC)
the lack of REQ_NOIDLE
Dave,
i.e. there's no point justifying a behaviour with we could do this
in future so lets ignore the impact on current users...
Sure, I am happy if we find a solution that
is good for both of us or filesystem and block in other word.
e.g. what happens if a user has a mixed workload - one
Mike,
I am happy to see that
guys from filesystem to the block subsystem
have been discussing how to handle barriers in each layer
almost independently.
Merging the barriers and replacing it with a single FLUSH
by accepting a lot of writes
is the reason for deferring barriers in writeboost.
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
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
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
On Wed, Oct 02, 2013 at 08:01:45PM -0400, Mikulas Patocka wrote:
>
>
> On Tue, 1 Oct 2013, Joe Thornber wrote:
>
> > > Alternatively, delaying them will stall the filesystem because it's
> > > waiting for said REQ_FUA IO to complete. For example, journal writes
> > > in XFS are extremely IO
On Wed, Oct 02, 2013 at 08:01:45PM -0400, Mikulas Patocka wrote:
On Tue, 1 Oct 2013, Joe Thornber wrote:
Alternatively, delaying them will stall the filesystem because it's
waiting for said REQ_FUA IO to complete. For example, journal writes
in XFS are extremely IO latency
On Tue, 1 Oct 2013, Joe Thornber wrote:
> > Alternatively, delaying them will stall the filesystem because it's
> > waiting for said REQ_FUA IO to complete. For example, journal writes
> > in XFS are extremely IO latency sensitive in workloads that have a
> > signifincant number of ordering
On Tue, 1 Oct 2013, Joe Thornber wrote:
Alternatively, delaying them will stall the filesystem because it's
waiting for said REQ_FUA IO to complete. For example, journal writes
in XFS are extremely IO latency sensitive in workloads that have a
signifincant number of ordering constraints
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
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.
It
Hi,
Two major progress:
1) .ctr accepts segment size so .ctr now accepts 3 arguments:
.
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 had the parameter embedded previously
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 Wed, Sep 25 2013 at 9:47pm -0400,
Akira Hayakawa wrote:
> Hi, Mike
>
> The monolithic source code (3.2k)
> is nicely splitted into almost 20 *.c files
> according to the functionality and
> data strucutures in OOP style.
>
> The aim of this posting
> is to share how the splitting looks
On Wed, Sep 25 2013 at 9:47pm -0400,
Akira Hayakawa ruby.w...@gmail.com wrote:
Hi, Mike
The monolithic source code (3.2k)
is nicely splitted into almost 20 *.c files
according to the functionality and
data strucutures in OOP style.
The aim of this posting
is to share how the splitting
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
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:
> 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
--
To
On Tue, Sep 24 2013 at 8:20am -0400,
Akira Hayakawa wrote:
> 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.
I
On Tue, Sep 24 2013 at 8:20am -0400,
Akira Hayakawa ruby.w...@gmail.com wrote:
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
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
--
To unsubscribe
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
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,
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
34 matches
Mail list logo
