On 04/13/2016 12:50 PM, Ming Lei wrote:
On Thu, Apr 14, 2016 at 12:14 AM, Jens Axboe <axboe@xxxxxx> wrote:
On Wed, Apr 13 2016, Jens Axboe wrote:
On Wed, Apr 13 2016, Ming Lei wrote:
+static ssize_t queue_wc_store(struct request_queue *q, const char *page,
+ size_t count)
+{
+ int set = -1;
+
+ if (!strncmp(page, "write back", 10))
+ set = 1;
+ else if (!strncmp(page, "write through", 13) ||
+ !strncmp(page, "none", 4))
+ set = 0;
+
+ if (set == -1)
+ return -EINVAL;
+
+ spin_lock_irq(q->queue_lock);
+ if (set)
+ queue_flag_set(QUEUE_FLAG_WC, q);
+ else
+ queue_flag_clear(QUEUE_FLAG_WC, q);
+ spin_unlock_irq(q->queue_lock);
When the write cache (queue)flag is changed, I guess we need to change
q->flush_flags via blk_queue_write_cache() too? Otherwise, the change
on write cache flag can't affect block flush behaviour.
BTW, looks the flush_flags has been redundant after this patch, can
we just kill it in the future?
How about we fold both those concerns into one? Kill off ->flush_flags,
and that then fixes the other part as well. Like the below, untested.
Minor screwup in target_core_iblock.c and a missing unsigned -> long
conversion in dm. Also changed the dm part to pass by value, not
reference.
The patch Looks fine.
Sounds good, I'll queue it up.
Also has another question about the sysfs interface for changing cache type:
how to make kernel's view consistent with device's cache type setting?
For example, someone changes cache type from writeback to writethrough
by the sysfs interface, but the type inside device is still writeback, then may
cause trouble after kernel doesn't handle flush.
I'm not too worried about that, it's more the fact that we lose the
original driver signaled state when that happens. Might be a good idea
to have a user settable flag, but still retain the driver setting.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
