You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been using your module and so far it has been working great. Thank you for your work in this.
An issue that I have encountered:
a. When a HDD ( The cached block device ) is dropped off (For example: The disk is dead or someone pulled the disk out), the system will encounter a flood of kernel/syslog messages when will then be filling up the /var/log very quickly.
The host would then require a sysrq reboot due to /var/log being filled up with the following messages:
I am not sure whether if this would be the right place to be raising this and if this is expected
I was thinking that this issue (The flooding of the kernel messages) could be because when a cached block device is dropped suddenly, writeboost would still continue to try flushing the data back to the failed cached block device
A solution that I was thinking of, is to either suppress/filter out the "blk_partition_remap" messages so that the /var/log doesn't get filled up at least
Any ideas ?
Thanks
The text was updated successfully, but these errors were encountered:
Hi,
I have been using your module and so far it has been working great. Thank you for your work in this.
An issue that I have encountered:
a. When a HDD ( The cached block device ) is dropped off (For example: The disk is dead or someone pulled the disk out), the system will encounter a flood of kernel/syslog messages when will then be filling up the /var/log very quickly.
The host would then require a sysrq reboot due to /var/log being filled up with the following messages:
The setup that I have:
lsblk (wb_sdi, wb_sdj are the writeboost devices and a lvm volume is created on top of it):
writeboost settings:
I am not sure whether if this would be the right place to be raising this and if this is expected
I was thinking that this issue (The flooding of the kernel messages) could be because when a cached block device is dropped suddenly, writeboost would still continue to try flushing the data back to the failed cached block device
A solution that I was thinking of, is to either suppress/filter out the "blk_partition_remap" messages so that the /var/log doesn't get filled up at least
Any ideas ?
Thanks
The text was updated successfully, but these errors were encountered: