staging: writeboost: Add dm-writeboost

This patch adds dm-writeboost to staging tree.

dm-writeboost is a log-structured SSD-caching driver. It caches data in log-structured way on the cache device so that the performance is maximized.

The merit of putting this driver in staging tree is to make it possible to get more feedback from users and polish the codes.

Signed-off-by Akira Hayakawa <[email protected]>

Quoted 11 lines · Akira Hayakawa

This patch adds dm-writeboost to staging tree.

dm-writeboost is a log-structured SSD-caching driver. It caches data in log-structured way on the cache device so that the performance is maximized.

The merit of putting this driver in staging tree is to make it possible to get more feedback from users and polish the codes.

Signed-off-by Akira Hayakawa <[email protected]>

Joe Thornber Nacked this from going into staging based on his further review of the code. On the basis that you should _not_ be copying all pages associated with each bio into an in-core buffer. Have you addressed that fundamental problem?

But taking a step back: Why do you think going into staging actually helps you? Anyone who is willing to test this code should be able to apply a patch to their kernel. Having to feed changes to Greg to deliver updates to any early consumers of this _EXPERIMENTAL_ target seems misplaced when you consider that Joe has detailed important fixes, capabilties and tools that need addressing before anyone should trust their production data to dm-writeboost.

I think you're completely missing that you are pushing _hard_ for this target to go upstream before it is actually ready. In doing so you're so hung up on that "upstream" milestone that you cannot appreciate the reluctance that Joe and I have given the quantity of code you're pushing -- especially when coupled with the limited utility of dm-writeboost in comparison with full featured upstream drivers like dm-cache and bcache.

As for this v2, you didn't detail what you changed (I can obviously apply v1 and then v2 to see the difference but a brief summary would be helpful in general when you revise a patch)

But one inline comment:

drivers/staging/writeboost/TODO line 3

Quoted 9 lines

drivers/staging/writeboost/TODO new file +3 -0

new file mode 100644
index 0000000..761a9fe
@@ -0,0 +1,52 @@
+TODO:
+
+- Get the GitExtract test so it's performance is similar to raw spindle.

No, the whole point of a write cache is to improve performance. You should be trying to surpass the performance of the raw spindle.

1. Writeboost shouldn't split the bio into 4KB chunks. No. It is necessary.
I know WALB (https://github.com/starpos/walb) logs data without splitting but the data structure becomes complicated. If you read my code carefully, you will notice that splitting helps the design simplicity and performance.

This is the first time I see someone claiming that reducing the request size improves performance. I don't know any SSD model for which splitting requests improves performance.

Writeboost batches number of writes into a log (that is 512KB large) and submits to SSD which maximizes the throughput and the lifetime of the SSD.

Quoted 2 lines · Akira Hayakawa

Writeboost batches number of writes into a log (that is 512KB large) and submits to SSD which maximizes the throughput and the lifetime of the SSD.

Does this mean that dm-writeboost is similar to btier ? If so, this makes me wonder which of these two subsystems would be the best candidate for upstream inclusion. As far as I know btier doesn't split bio's. The source code of btier can be downloaded from http://sourceforge.net/projects/tier/.

Quoted 8 lines · Bart Van Assche

Quoted 4 lines · Akira Hayakawa

Writeboost batches number of writes into a log (that is 512KB large) and submits to SSD
which maximizes the throughput and the lifetime of the SSD.

Quoted 4 lines

Does this mean that dm-writeboost is similar to btier ? If so, this makes me wonder which of these two subsystems would be the best candidate for upstream inclusion. As far as I know btier doesn't split bio's. The source code of btier can be downloaded from http://sourceforge.net/projects/tier/.

No, Btier is a caching (tiering actually but there is little difference) software like bcache or dm-cache, which are are open source software reimplementations of things like LSI CacheCade.

OTOH dm-writeboost is an open source software reimplementation of a BBWC (battery backed write cache) of disk controllers.

For this reason dm-writeboost was unique in its class and no doubt it could be blazing fast (untested by me) if correctly implemented, orders of magnitude faster than caching softwares, and I was looking forward to see dm-writeboost into the kernel.

But me too I think that dm-writeboost really needs not to split BIOs (whoever thinks differently has probably never looked at perf while a very fast raid system was writing data), and as much as possible not perform memcopy, and would need to detect and skip sequential I/O (adding logic to still be safe on sync + power loss) and use writethrough for that which I think it also doesn't do. These are absolute requirements for high performance storage systems in the 2-20 gigabytes per second range. If Akira doesn't see the need to not perform memcpy or not split BIOs or not skip sequential I/O it is most certainly because he hasn't tried to build a high performance storage system. Unfortunately I think that high performance storage systems are indeed the main market for writeboost, so that's why these things are needed.

Another important missing feature is way to decommission writeboost or put it into writethrough mode, so to be able to snapshot the underlying device. This is totally needed in an industrial-grade production system.

OTOH read caching would have been useless for writeboost btw imho, and hence counterproductive. Layer dm-cache or bcache on top of writeboost if you need that.

S.

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

The SSD-caching should be log-structured.

However, after looking at the current code, and using it I think it's a long, long way from being ready for production. As we've already discussed there are some very naive design decisions in there, such as copying every bio payload to another memory buffer, splitting all io down to 4k. Think about the cpu overhead and memory consumption! Think about how it will perform when memory is constrained and it can't allocate many of those rambufs! I'm sure more issues will be found if I read further.

Mike raised the question of why you want this in the kernel so much? You'd find none of the distros would support it; so it doesn't widen your audience much. It's far better for you to maintain it outside of the kernel at this point. Any users will be bold, adventurous people, who will be quite capable of building a kernel module.

I'm sorry to have disappointed you so, but if I let this go upstream it would mean a massive amount of support work for me, not to mention a damaged reputation for dm.

Quoted 1 line · Akira Hayakawa

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 way from being ready for production. As we've already discussed there are some very naive design decisions in there, such as copying every bio payload to another memory buffer, splitting all io down to 4k. Think about the cpu overhead and memory consumption! Think about how it will perform when memory is constrained and it can't allocate many of those rambufs! I'm sure more issues will be found if I read further.

I'm sorry to have disappointed you so, but if I let this go upstream it would mean a massive amount of support work for me, not to mention a damaged reputation for dm.

Mike raised the question of why you want this in the kernel so much? You'd find none of the distros would support it; so it doesn't widen your audience much. It's far better for you to maintain it outside of the kernel at this point. Any users will be bold, adventurous people, who will be quite capable of building a kernel module.

- Joe

Quoted 8 lines

However, after looking at the current code, and using it I think it's a long, long way from being ready for production. As we've already discussed there are some very naive design decisions in there, such as copying every bio payload to another memory buffer, splitting all io down to 4k. Think about the cpu overhead and memory consumption! Think about how it will perform when memory is constrained and it can't allocate many of those rambufs! I'm sure more issues will be found if I read further.

These decisions are made based on measurement. They are not naive. I am a man who dislikes performance optimization without measurement. As a result, I regard things brought by the simplicity much important than what's from other design decisions possible.

About the CPU consumption,
the average CPU consumption while performing random write fio with consumer level SSD is only 3% or so,
which is 5 times efficient than bcache per iops.

With RAM-backed cache device, it reaches about 1.5GB/sec throughput. Even in this case the CPU consumption is only 12%.
Please see this post,
http://www.redhat.com/archives/dm-devel/2014-February/msg00000.html

I don't think the CPU consumption is small enough to ignore.

About the memory consumption,
you seem to misunderstand the fact.
The rambufs are not dynamically allocated but statically. The default amount is 8MB and this is usually not to argue.

Quoted 5 lines

Mike raised the question of why you want this in the kernel so much? You'd find none of the distros would support it; so it doesn't widen your audience much. It's far better for you to maintain it outside of the kernel at this point. Any users will be bold, adventurous people, who will be quite capable of building a kernel module.

Some people deploy Writeboost in their daily use.
The sound of "log-structured" seems to easily attract storage guys' attention. If this driver is merged into upstream, I think it gains many audience and thus feedback.
When my driver was introduced by Phoronix before, it actually drew attentions. They must wait for Writeboost become available in upstream.
http://www.phoronix.com/scan.php?page=news_item&px=MTQ1Mjg

Quoted 3 lines

I'm sorry to have disappointed you so, but if I let this go upstream it would mean a massive amount of support work for me, not to mention a damaged reputation for dm.

If you read the code further, you will find how simple the mechanism is. Not to mention the code itself is.

- Akira

Quoted 19 lines · Joe Thornber

Quoted 1 line · Akira Hayakawa

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 way from being ready for production. As we've already discussed there are some very naive design decisions in there, such as copying every bio payload to another memory buffer, splitting all io down to 4k. Think about the cpu overhead and memory consumption! Think about how it will perform when memory is constrained and it can't allocate many of those rambufs! I'm sure more issues will be found if I read further.

I'm sorry to have disappointed you so, but if I let this go upstream it would mean a massive amount of support work for me, not to mention a damaged reputation for dm.

Quoted 8 lines

Mike raised the question of why you want this in the kernel so much? You'd find none of the distros would support it; so it doesn't widen your audience much. It's far better for you to maintain it outside of the kernel at this point. Any users will be bold, adventurous people, who will be quite capable of building a kernel module.

- Joe

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

If I understand it correctly, the whole idea indeed is very simple, the consumer/provider and circular buffer model. use SSD as a circular write buffer, write flush thread stores incoming writes to this buffer sequentially as provider, and writeback thread write those data logs sequentially into backing device as consumer.

If writeboost can do that without any random writes, then probably it can save SSD/FTL of doing a lot of dirty jobs, and utilize the faster sequential read/write performance from SSD. That'll be awesome. However, I saw every data log segment in its design has meta data header, like dirty_bits, so I guess writeboost has to randomly write those data headers of stored data logs in SSD; also, splitting all bio into 4KB will hurt its ability to get max raw SSD throughput, modern NAND Flash has pages much bigger than 4KB; so overall I think the actual benefits writeboost gets from this design will be discounted.

The good thing is that it seems writeboost doesn't use garbage collection to clean old invalid logs, this will avoid the double garage collection effect other caching module has, which essentially both caching module and internal SSD will perform garbage collections twice.

And one question, how long will be data logs replay time during init, if SSD is almost full of dirty data logs?

If I understand it correctly, the whole idea indeed is very simple, the consumer/provider and circular buffer model. use SSD as a circular write buffer, write flush thread stores incoming writes to this buffer sequentially as provider, and writeback thread write those data logs sequentially into backing device as consumer.

If writeboost can do that without any random writes, then probably it can save SSD/FTL of doing a lot of dirty jobs, and utilize the faster sequential read/write performance from SSD. That'll be awesome. However, I saw every data log segment in its design has meta data header, like dirty_bits, so I guess writeboost has to randomly write those data headers of stored data logs in SSD; also, splitting all bio into 4KB will hurt its ability to get max raw SSD throughput, modern NAND Flash has pages much bigger than 4KB; so overall I think the actual benefits writeboost gets from this design will be discounted.

The good thing is that it seems writeboost doesn't use garbage collection to clean old invalid logs, this will avoid the double garage collection effect other caching module has, which essentially both caching module and internal SSD will perform garbage collections twice.

And one question, how long will be data logs replay time during init, if SSD is almost full of dirty data logs?

Jianjian

Quoted 77 lines · Akira Hayakawa

Quoted 8 lines

However, after looking at the current code, and using it I think it's a long, long way from being ready for production. As we've already discussed there are some very naive design decisions in there, such as copying every bio payload to another memory buffer, splitting all io down to 4k. Think about the cpu overhead and memory consumption! Think about how it will perform when memory is constrained and it can't allocate many of those rambufs! I'm sure more issues will be found if I read further.

These decisions are made based on measurement. They are not naive. I am a man who dislikes performance optimization without measurement. As a result, I regard things brought by the simplicity much important than what's from other design decisions possible.

About the CPU consumption,
the average CPU consumption while performing random write fio with consumer level SSD is only 3% or so,
which is 5 times efficient than bcache per iops.

With RAM-backed cache device, it reaches about 1.5GB/sec throughput. Even in this case the CPU consumption is only 12%.
Please see this post,
http://www.redhat.com/archives/dm-devel/2014-February/msg00000.html

I don't think the CPU consumption is small enough to ignore.

About the memory consumption,
you seem to misunderstand the fact.
The rambufs are not dynamically allocated but statically. The default amount is 8MB and this is usually not to argue.

Quoted 5 lines

Mike raised the question of why you want this in the kernel so much? You'd find none of the distros would support it; so it doesn't widen your audience much. It's far better for you to maintain it outside of the kernel at this point. Any users will be bold, adventurous people, who will be quite capable of building a kernel module.

Some people deploy Writeboost in their daily use.
The sound of "log-structured" seems to easily attract storage guys' attention. If this driver is merged into upstream, I think it gains many audience and thus feedback.
When my driver was introduced by Phoronix before, it actually drew attentions. They must wait for Writeboost become available in upstream.
http://www.phoronix.com/scan.php?page=news_item&px=MTQ1Mjg

Quoted 3 lines

I'm sorry to have disappointed you so, but if I let this go upstream it would mean a massive amount of support work for me, not to mention a damaged reputation for dm.

If you read the code further, you will find how simple the mechanism is. Not to mention the code itself is.

- Akira

Quoted 25 lines · Joe Thornber

Quoted 1 line · Akira Hayakawa

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 way from being ready for production. As we've already discussed there are some very naive design decisions in there, such as copying every bio payload to another memory buffer, splitting all io down to 4k. Think about the cpu overhead and memory consumption! Think about how it will perform when memory is constrained and it can't allocate many of those rambufs! I'm sure more issues will be found if I read further.

I'm sorry to have disappointed you so, but if I let this go upstream it would mean a massive amount of support work for me, not to mention a damaged reputation for dm.

Mike raised the question of why you want this in the kernel so much? You'd find none of the distros would support it; so it doesn't widen your audience much. It's far better for you to maintain it outside of the kernel at this point. Any users will be bold, adventurous people, who will be quite capable of building a kernel module.

Quoted 7 lines

Quoted 2 lines

- Joe

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

The major reason is, it needs to read full 512KB segment to calculate checksum to know if the log isn't half written.
(Read 500GB SSD that performs 500MB/sec seqread spends 1000secs)

Hi,

Jianjian, You really get a point at the fundamental design.

Quoted 6 lines

If I understand it correctly, the whole idea indeed is very simple, the consumer/provider and circular buffer model. use SSD as a circular write buffer, write flush thread stores incoming writes to this buffer sequentially as provider, and writeback thread write those data logs sequentially into backing device as consumer.

Quoted 9 lines

If writeboost can do that without any random writes, then probably it can save SSD/FTL of doing a lot of dirty jobs, and utilize the faster sequential read/write performance from SSD. That'll be awesome. However, I saw every data log segment in its design has meta data header, like dirty_bits, so I guess writeboost has to randomly write those data headers of stored data logs in SSD; also, splitting all bio into 4KB will hurt its ability to get max raw SSD throughput, modern NAND Flash has pages much bigger than 4KB; so overall I think the actual benefits writeboost gets from this design will be discounted.

You understand *almost* correctly.

Writeboost has two circular buffers, not one; RAM buffers and SSD. The incoming bio is split into 4KB chunks at the virtual make_request and are NOT directly remapped to the SSD.
As you mentioned, if I designed so, many update on the metadata happens. That's really bad since SSD is very bad at small update.

Actually, the 4KB bio is first stored in RAM buffer, which is 512KB large. There are (512-4)/4=127 4KB bio data stored in the RAM buffer and 4KB metadata section at the head is made after that.

The RAM buffer is now called "log" and as you mentioned, flushed to the SSD as 512KB sequential write. This definitely maximizes throughput and lifetime.

Unfortunately, this is not always the case because of barrier request handlings. But, when the writes is really heavy (e.g. massive dirty page writeback), Writeboost works as above.

Quoted 5 lines

The good thing is that it seems writeboost doesn't use garbage collection to clean old invalid logs, this will avoid the double garage collection effect other caching module has, which essentially both caching module and internal SSD will perform garbage collections twice.

Yes. And I believe SSDs can remove wear-leveling if I used it as fairly sequential. Am I right? Indeed, Writeboost is really SSD frinedly.

Quoted 2 lines

And one question, how long will be data logs replay time during init, if SSD is almost full of dirty data logs?

Sorry, I don't have a data now but it's slow as you may imagine. I will measure the time on later.

The major reason is, it needs to read full 512KB segment to calculate checksum to know if the log isn't half written.
(Read 500GB SSD that performs 500MB/sec seqread spends 1000secs)
I think making the procedure done in parallel to exploit the full internal parallelism inside SSD may improve performance but it's just the matter of coefficient down from 1 to 1/n. Definitely, Writeboost isn't fit for a machine that needs reboot frequently (e.g. desktop).

There is a way to reduce the init time. We can dump "what is the latest log written back" on the superblock. This can skip readings that aren't essential.

The corresponding code is replay_log_on_cache() function. Please read if you are interested.

Thanks,

- Akira

Quoted 118 lines · Jianjian Huo

If I understand it correctly, the whole idea indeed is very simple, the consumer/provider and circular buffer model. use SSD as a circular write buffer, write flush thread stores incoming writes to this buffer sequentially as provider, and writeback thread write those data logs sequentially into backing device as consumer.

If writeboost can do that without any random writes, then probably it can save SSD/FTL of doing a lot of dirty jobs, and utilize the faster sequential read/write performance from SSD. That'll be awesome. However, I saw every data log segment in its design has meta data header, like dirty_bits, so I guess writeboost has to randomly write those data headers of stored data logs in SSD; also, splitting all bio into 4KB will hurt its ability to get max raw SSD throughput, modern NAND Flash has pages much bigger than 4KB; so overall I think the actual benefits writeboost gets from this design will be discounted.

The good thing is that it seems writeboost doesn't use garbage collection to clean old invalid logs, this will avoid the double garage collection effect other caching module has, which essentially both caching module and internal SSD will perform garbage collections twice.

And one question, how long will be data logs replay time during init, if SSD is almost full of dirty data logs?

Jianjian

Quoted 77 lines · Akira Hayakawa

Quoted 8 lines

However, after looking at the current code, and using it I think it's a long, long way from being ready for production. As we've already discussed there are some very naive design decisions in there, such as copying every bio payload to another memory buffer, splitting all io down to 4k. Think about the cpu overhead and memory consumption! Think about how it will perform when memory is constrained and it can't allocate many of those rambufs! I'm sure more issues will be found if I read further.

These decisions are made based on measurement. They are not naive. I am a man who dislikes performance optimization without measurement. As a result, I regard things brought by the simplicity much important than what's from other design decisions possible.

About the CPU consumption,
the average CPU consumption while performing random write fio with consumer level SSD is only 3% or so,
which is 5 times efficient than bcache per iops.

With RAM-backed cache device, it reaches about 1.5GB/sec throughput. Even in this case the CPU consumption is only 12%.
Please see this post,
http://www.redhat.com/archives/dm-devel/2014-February/msg00000.html

I don't think the CPU consumption is small enough to ignore.

About the memory consumption,
you seem to misunderstand the fact.
The rambufs are not dynamically allocated but statically. The default amount is 8MB and this is usually not to argue.

Quoted 5 lines

Mike raised the question of why you want this in the kernel so much? You'd find none of the distros would support it; so it doesn't widen your audience much. It's far better for you to maintain it outside of the kernel at this point. Any users will be bold, adventurous people, who will be quite capable of building a kernel module.

Some people deploy Writeboost in their daily use.
The sound of "log-structured" seems to easily attract storage guys' attention. If this driver is merged into upstream, I think it gains many audience and thus feedback.
When my driver was introduced by Phoronix before, it actually drew attentions. They must wait for Writeboost become available in upstream.
http://www.phoronix.com/scan.php?page=news_item&px=MTQ1Mjg

Quoted 3 lines

I'm sorry to have disappointed you so, but if I let this go upstream it would mean a massive amount of support work for me, not to mention a damaged reputation for dm.

If you read the code further, you will find how simple the mechanism is. Not to mention the code itself is.

- Akira

Quoted 25 lines · Joe Thornber

Quoted 1 line · Akira Hayakawa

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 way from being ready for production. As we've already discussed there are some very naive design decisions in there, such as copying every bio payload to another memory buffer, splitting all io down to 4k. Think about the cpu overhead and memory consumption! Think about how it will perform when memory is constrained and it can't allocate many of those rambufs! I'm sure more issues will be found if I read further.

I'm sorry to have disappointed you so, but if I let this go upstream it would mean a massive amount of support work for me, not to mention a damaged reputation for dm.

Mike raised the question of why you want this in the kernel so much? You'd find none of the distros would support it; so it doesn't widen your audience much. It's far better for you to maintain it outside of the kernel at this point. Any users will be bold, adventurous people, who will be quite capable of building a kernel module.

Quoted 7 lines

Quoted 2 lines

- Joe

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

Hi,

Jianjian, You really get a point at the fundamental design.

Quoted 6 lines

If I understand it correctly, the whole idea indeed is very simple, the consumer/provider and circular buffer model. use SSD as a circular write buffer, write flush thread stores incoming writes to this buffer sequentially as provider, and writeback thread write those data logs sequentially into backing device as consumer.

Quoted 9 lines

If writeboost can do that without any random writes, then probably it can save SSD/FTL of doing a lot of dirty jobs, and utilize the faster sequential read/write performance from SSD. That'll be awesome. However, I saw every data log segment in its design has meta data header, like dirty_bits, so I guess writeboost has to randomly write those data headers of stored data logs in SSD; also, splitting all bio into 4KB will hurt its ability to get max raw SSD throughput, modern NAND Flash has pages much bigger than 4KB; so overall I think the actual benefits writeboost gets from this design will be discounted.

You understand *almost* correctly.

Writeboost has two circular buffers, not one; RAM buffers and SSD. The incoming bio is split into 4KB chunks at the virtual make_request and are NOT directly remapped to the SSD.
As you mentioned, if I designed so, many update on the metadata happens. That's really bad since SSD is very bad at small update.

Actually, the 4KB bio is first stored in RAM buffer, which is 512KB large. There are (512-4)/4=127 4KB bio data stored in the RAM buffer and 4KB metadata section at the head is made after that.

The RAM buffer is now called "log" and as you mentioned, flushed to the SSD as 512KB sequential write. This definitely maximizes throughput and lifetime.

Unfortunately, this is not always the case because of barrier request handlings. But, when the writes is really heavy (e.g. massive dirty page writeback), Writeboost works as above.

Quoted 5 lines

The good thing is that it seems writeboost doesn't use garbage collection to clean old invalid logs, this will avoid the double garage collection effect other caching module has, which essentially both caching module and internal SSD will perform garbage collections twice.

Yes. And I believe SSDs can remove wear-leveling if I used it as fairly sequential. Am I right? Indeed, Writeboost is really SSD frinedly.

Quoted 2 lines

And one question, how long will be data logs replay time during init, if SSD is almost full of dirty data logs?

Sorry, I don't have a data now but it's slow as you may imagine. I will measure the time on later.

The major reason is, it needs to read full 512KB segment to calculate checksum to know if the log isn't half written.
(Read 500GB SSD that performs 500MB/sec seqread spends 1000secs)
I think making the procedure done in parallel to exploit the full internal parallelism inside SSD may improve performance but it's just the matter of coefficient down from 1 to 1/n. Definitely, Writeboost isn't fit for a machine that needs reboot frequently (e.g. desktop).

There is a way to reduce the init time. We can dump "what is the latest log written back" on the superblock. This can skip readings that aren't essential.

The corresponding code is replay_log_on_cache() function. Please read if you are interested.

Thanks,

- Akira

Quoted 118 lines · Jianjian Huo

If I understand it correctly, the whole idea indeed is very simple, the consumer/provider and circular buffer model. use SSD as a circular write buffer, write flush thread stores incoming writes to this buffer sequentially as provider, and writeback thread write those data logs sequentially into backing device as consumer.

If writeboost can do that without any random writes, then probably it can save SSD/FTL of doing a lot of dirty jobs, and utilize the faster sequential read/write performance from SSD. That'll be awesome. However, I saw every data log segment in its design has meta data header, like dirty_bits, so I guess writeboost has to randomly write those data headers of stored data logs in SSD; also, splitting all bio into 4KB will hurt its ability to get max raw SSD throughput, modern NAND Flash has pages much bigger than 4KB; so overall I think the actual benefits writeboost gets from this design will be discounted.

The good thing is that it seems writeboost doesn't use garbage collection to clean old invalid logs, this will avoid the double garage collection effect other caching module has, which essentially both caching module and internal SSD will perform garbage collections twice.

And one question, how long will be data logs replay time during init, if SSD is almost full of dirty data logs?

Jianjian

Quoted 77 lines · Akira Hayakawa

Quoted 8 lines

However, after looking at the current code, and using it I think it's a long, long way from being ready for production. As we've already discussed there are some very naive design decisions in there, such as copying every bio payload to another memory buffer, splitting all io down to 4k. Think about the cpu overhead and memory consumption! Think about how it will perform when memory is constrained and it can't allocate many of those rambufs! I'm sure more issues will be found if I read further.

These decisions are made based on measurement. They are not naive. I am a man who dislikes performance optimization without measurement. As a result, I regard things brought by the simplicity much important than what's from other design decisions possible.

About the CPU consumption,
the average CPU consumption while performing random write fio with consumer level SSD is only 3% or so,
which is 5 times efficient than bcache per iops.

With RAM-backed cache device, it reaches about 1.5GB/sec throughput. Even in this case the CPU consumption is only 12%.
Please see this post,
http://www.redhat.com/archives/dm-devel/2014-February/msg00000.html

I don't think the CPU consumption is small enough to ignore.

About the memory consumption,
you seem to misunderstand the fact.
The rambufs are not dynamically allocated but statically. The default amount is 8MB and this is usually not to argue.

Quoted 5 lines

Mike raised the question of why you want this in the kernel so much? You'd find none of the distros would support it; so it doesn't widen your audience much. It's far better for you to maintain it outside of the kernel at this point. Any users will be bold, adventurous people, who will be quite capable of building a kernel module.

Some people deploy Writeboost in their daily use.
The sound of "log-structured" seems to easily attract storage guys' attention. If this driver is merged into upstream, I think it gains many audience and thus feedback.
When my driver was introduced by Phoronix before, it actually drew attentions. They must wait for Writeboost become available in upstream.
http://www.phoronix.com/scan.php?page=news_item&px=MTQ1Mjg

Quoted 3 lines

I'm sorry to have disappointed you so, but if I let this go upstream it would mean a massive amount of support work for me, not to mention a damaged reputation for dm.

If you read the code further, you will find how simple the mechanism is. Not to mention the code itself is.

- Akira

Quoted 25 lines · Joe Thornber

Quoted 1 line · Akira Hayakawa

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 way from being ready for production. As we've already discussed there are some very naive design decisions in there, such as copying every bio payload to another memory buffer, splitting all io down to 4k. Think about the cpu overhead and memory consumption! Think about how it will perform when memory is constrained and it can't allocate many of those rambufs! I'm sure more issues will be found if I read further.

I'm sorry to have disappointed you so, but if I let this go upstream it would mean a massive amount of support work for me, not to mention a damaged reputation for dm.

Mike raised the question of why you want this in the kernel so much? You'd find none of the distros would support it; so it doesn't widen your audience much. It's far better for you to maintain it outside of the kernel at this point. Any users will be bold, adventurous people, who will be quite capable of building a kernel module.

Quoted 7 lines

Quoted 2 lines

- Joe

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

How about invalidating previous writes on same sector address? if first write is stored in one 512KB log in SSD, later when user write the same address, will writeboost invalid old write by updating meta data header in place in that 512KB log? and other meta data like superblock, will writeboost will update them in place? if writeboost has those frequent random in-place updates, probably those benefits except utilizing the faster sequential writes will be much discounted.

Even if writeboost write everything sequentially, probably SSD won't be able to recognize that and do its own wear-leveling whatsoever. It will be easier, since there is no need to move cold data, etc.

Generally, SSDs vary a lot, IMHO, one certain optimization technique may work for certain model, but may not work for others, since they internal NAND Flash management algorithms can be very different.

Quoted 31 lines · Akira Hayakawa

Hi,

Jianjian, You really get a point at the fundamental design.

Quoted 6 lines

If I understand it correctly, the whole idea indeed is very simple, the consumer/provider and circular buffer model. use SSD as a circular write buffer, write flush thread stores incoming writes to this buffer sequentially as provider, and writeback thread write those data logs sequentially into backing device as consumer.

Quoted 9 lines

If writeboost can do that without any random writes, then probably it can save SSD/FTL of doing a lot of dirty jobs, and utilize the faster sequential read/write performance from SSD. That'll be awesome. However, I saw every data log segment in its design has meta data header, like dirty_bits, so I guess writeboost has to randomly write those data headers of stored data logs in SSD; also, splitting all bio into 4KB will hurt its ability to get max raw SSD throughput, modern NAND Flash has pages much bigger than 4KB; so overall I think the actual benefits writeboost gets from this design will be discounted.

You understand *almost* correctly.

Writeboost has two circular buffers, not one; RAM buffers and SSD. The incoming bio is split into 4KB chunks at the virtual make_request and are NOT directly remapped to the SSD.
As you mentioned, if I designed so, many update on the metadata happens. That's really bad since SSD is very bad at small update.

Actually, the 4KB bio is first stored in RAM buffer, which is 512KB large. There are (512-4)/4=127 4KB bio data stored in the RAM buffer and 4KB metadata section at the head is made after that.

Quoted 7 lines

The RAM buffer is now called "log" and as you mentioned, flushed to the SSD as 512KB sequential write. This definitely maximizes throughput and lifetime.

Unfortunately, this is not always the case because of barrier request handlings. But, when the writes is really heavy (e.g. massive dirty page writeback), Writeboost works as above.

How about invalidating previous writes on same sector address? if first write is stored in one 512KB log in SSD, later when user write the same address, will writeboost invalid old write by updating meta data header in place in that 512KB log? and other meta data like superblock, will writeboost will update them in place? if writeboost has those frequent random in-place updates, probably those benefits except utilizing the faster sequential writes will be much discounted.

Quoted 8 lines

Quoted 5 lines

The good thing is that it seems writeboost doesn't use garbage collection to clean old invalid logs, this will avoid the double garage collection effect other caching module has, which essentially both caching module and internal SSD will perform garbage collections twice.

Yes. And I believe SSDs can remove wear-leveling if I used it as fairly sequential. Am I right? Indeed, Writeboost is really SSD frinedly.

Even if writeboost write everything sequentially, probably SSD won't be able to recognize that and do its own wear-leveling whatsoever. It will be easier, since there is no need to move cold data, etc.

Generally, SSDs vary a lot, IMHO, one certain optimization technique may work for certain model, but may not work for others, since they internal NAND Flash management algorithms can be very different.

Quoted 142 lines

Quoted 2 lines

And one question, how long will be data logs replay time during init, if SSD is almost full of dirty data logs?

Sorry, I don't have a data now but it's slow as you may imagine. I will measure the time on later.

The major reason is, it needs to read full 512KB segment to calculate checksum to know if the log isn't half written.
(Read 500GB SSD that performs 500MB/sec seqread spends 1000secs)
I think making the procedure done in parallel to exploit the full internal parallelism inside SSD may improve performance but it's just the matter of coefficient down from 1 to 1/n. Definitely, Writeboost isn't fit for a machine that needs reboot frequently (e.g. desktop).

There is a way to reduce the init time. We can dump "what is the latest log written back" on the superblock. This can skip readings that aren't essential.

The corresponding code is replay_log_on_cache() function. Please read if you are interested.

Thanks,

- Akira

Quoted 118 lines · Jianjian Huo

If I understand it correctly, the whole idea indeed is very simple, the consumer/provider and circular buffer model. use SSD as a circular write buffer, write flush thread stores incoming writes to this buffer sequentially as provider, and writeback thread write those data logs sequentially into backing device as consumer.

If writeboost can do that without any random writes, then probably it can save SSD/FTL of doing a lot of dirty jobs, and utilize the faster sequential read/write performance from SSD. That'll be awesome. However, I saw every data log segment in its design has meta data header, like dirty_bits, so I guess writeboost has to randomly write those data headers of stored data logs in SSD; also, splitting all bio into 4KB will hurt its ability to get max raw SSD throughput, modern NAND Flash has pages much bigger than 4KB; so overall I think the actual benefits writeboost gets from this design will be discounted.

The good thing is that it seems writeboost doesn't use garbage collection to clean old invalid logs, this will avoid the double garage collection effect other caching module has, which essentially both caching module and internal SSD will perform garbage collections twice.

And one question, how long will be data logs replay time during init, if SSD is almost full of dirty data logs?

Jianjian

Quoted 77 lines · Akira Hayakawa

Quoted 8 lines

However, after looking at the current code, and using it I think it's a long, long way from being ready for production. As we've already discussed there are some very naive design decisions in there, such as copying every bio payload to another memory buffer, splitting all io down to 4k. Think about the cpu overhead and memory consumption! Think about how it will perform when memory is constrained and it can't allocate many of those rambufs! I'm sure more issues will be found if I read further.

These decisions are made based on measurement. They are not naive. I am a man who dislikes performance optimization without measurement. As a result, I regard things brought by the simplicity much important than what's from other design decisions possible.

About the CPU consumption,
the average CPU consumption while performing random write fio with consumer level SSD is only 3% or so,
which is 5 times efficient than bcache per iops.

With RAM-backed cache device, it reaches about 1.5GB/sec throughput. Even in this case the CPU consumption is only 12%.
Please see this post,
http://www.redhat.com/archives/dm-devel/2014-February/msg00000.html

I don't think the CPU consumption is small enough to ignore.

About the memory consumption,
you seem to misunderstand the fact.
The rambufs are not dynamically allocated but statically. The default amount is 8MB and this is usually not to argue.

Quoted 5 lines

Mike raised the question of why you want this in the kernel so much? You'd find none of the distros would support it; so it doesn't widen your audience much. It's far better for you to maintain it outside of the kernel at this point. Any users will be bold, adventurous people, who will be quite capable of building a kernel module.

Some people deploy Writeboost in their daily use.
The sound of "log-structured" seems to easily attract storage guys' attention. If this driver is merged into upstream, I think it gains many audience and thus feedback.
When my driver was introduced by Phoronix before, it actually drew attentions. They must wait for Writeboost become available in upstream.
http://www.phoronix.com/scan.php?page=news_item&px=MTQ1Mjg

Quoted 3 lines

I'm sorry to have disappointed you so, but if I let this go upstream it would mean a massive amount of support work for me, not to mention a damaged reputation for dm.

If you read the code further, you will find how simple the mechanism is. Not to mention the code itself is.

- Akira

Quoted 25 lines · Joe Thornber

Quoted 1 line · Akira Hayakawa

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 way from being ready for production. As we've already discussed there are some very naive design decisions in there, such as copying every bio payload to another memory buffer, splitting all io down to 4k. Think about the cpu overhead and memory consumption! Think about how it will perform when memory is constrained and it can't allocate many of those rambufs! I'm sure more issues will be found if I read further.

I'm sorry to have disappointed you so, but if I let this go upstream it would mean a massive amount of support work for me, not to mention a damaged reputation for dm.

Mike raised the question of why you want this in the kernel so much? You'd find none of the distros would support it; so it doesn't widen your audience much. It's far better for you to maintain it outside of the kernel at this point. Any users will be bold, adventurous people, who will be quite capable of building a kernel module.

Quoted 7 lines

Quoted 2 lines

- Joe

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

Quoted 8 lines

However, after looking at the current code, and using it I think it's a long, long way from being ready for production. As we've already discussed there are some very naive design decisions in there, such as copying every bio payload to another memory buffer, splitting all io down to 4k. Think about the cpu overhead and memory consumption! Think about how it will perform when memory is constrained and it can't allocate many of those rambufs! I'm sure more issues will be found if I read further.

These decisions are made based on measurement. They are not naive. I am a man who dislikes performance optimization without measurement. As a result, I regard things brought by the simplicity much important than what's from other design decisions possible.

About the CPU consumption,
the average CPU consumption while performing random write fio with consumer level SSD is only 3% or so,
which is 5 times efficient than bcache per iops.

With RAM-backed cache device, it reaches about 1.5GB/sec throughput. Even in this case the CPU consumption is only 12%.
Please see this post,
http://www.redhat.com/archives/dm-devel/2014-February/msg00000.html

I don't think the CPU consumption is small enough to ignore.

About the memory consumption,
you seem to misunderstand the fact.
The rambufs are not dynamically allocated but statically. The default amount is 8MB and this is usually not to argue.

Quoted 5 lines

Mike raised the question of why you want this in the kernel so much? You'd find none of the distros would support it; so it doesn't widen your audience much. It's far better for you to maintain it outside of the kernel at this point. Any users will be bold, adventurous people, who will be quite capable of building a kernel module.

Some people deploy Writeboost in their daily use.
The sound of "log-structured" seems to easily attract storage guys' attention. If this driver is merged into upstream, I think it gains many audience and thus feedback.
When my driver was introduced by Phoronix before, it actually drew attentions. They must wait for Writeboost become available in upstream.
http://www.phoronix.com/scan.php?page=news_item&px=MTQ1Mjg

Quoted 3 lines

I'm sorry to have disappointed you so, but if I let this go upstream it would mean a massive amount of support work for me, not to mention a damaged reputation for dm.

If you read the code further, you will find how simple the mechanism is. Not to mention the code itself is.

- Akira

Quoted 27 lines · Joe Thornber

Quoted 1 line · Akira Hayakawa

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 way from being ready for production. As we've already discussed there are some very naive design decisions in there, such as copying every bio payload to another memory buffer, splitting all io down to 4k. Think about the cpu overhead and memory consumption! Think about how it will perform when memory is constrained and it can't allocate many of those rambufs! I'm sure more issues will be found if I read further.

I'm sorry to have disappointed you so, but if I let this go upstream it would mean a massive amount of support work for me, not to mention a damaged reputation for dm.

Mike raised the question of why you want this in the kernel so much? You'd find none of the distros would support it; so it doesn't widen your audience much. It's far better for you to maintain it outside of the kernel at this point. Any users will be bold, adventurous people, who will be quite capable of building a kernel module.

- Joe