- 01 Jun, 2018 32 commits
-
-
Marcin Dziegielewski authored
In some cases, users can want set write buffer size manually, e.g. to adjust it to specific workload. This patch provides the possibility to set write buffer size via module parameter feature. Signed-off-by:
Marcin Dziegielewski <marcin.dziegielewski@intel.com> Signed-off-by:
Igor Konopko <igor.j.konopko@intel.com> Signed-off-by:
Matias Bjørling <mb@lightnvm.io> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Igor Konopko authored
When error occurs during bio_add_page on partial read path, pblk tries to free pages twice. Signed-off-by:
-
Igor Konopko authored
Currently in case of error caused by bio_pc_add_page in pblk_bio_add_pages two issues occur when calling from pblk_rb_read_to_bio(). First one is in pblk_bio_free_pages, since we are trying to free pages not allocated from our mempool. Second one is the warn from dma_pool_free, that we are trying to free NULL pointer dma. This commit fix both issues. Signed-off-by:
-
Hans Holmberg authored
Smeta write errors were previously ignored. Skip these lines instead and throw them back on the free list, so the chunks will go through a reset cycle before we attempt to use the line again. Signed-off-by:
Hans Holmberg <hans.holmberg@cnexlabs.com> Reviewed-by:
Javier González <javier@cnexlabs.com> Signed-off-by:
-
Hans Holmberg authored
Write failures should not happen under normal circumstances, so in order to bring the chunk back into a known state as soon as possible, evacuate all the valid data out of the line and let the fw judge if the block can be written to in the next reset cycle. Do this by introducing a new gc list for lines with failed writes, and ensure that the rate limiter allocates a small portion of the write bandwidth to get the job done. The lba list is saved in memory for use during gc as we cannot gurantee that the emeta data is readable if a write error occurred. Signed-off-by:
-
Hans Holmberg authored
The write error recovery path is incomplete, so rework the write error recovery handling to do resubmits directly from the write buffer. When a write error occurs, the remaining sectors in the chunk are mapped out and invalidated and the request inserted in a resubmit list. The writer thread checks if there are any requests to resubmit, scans and invalidates any lbas that have been overwritten by later writes and resubmits the failed entries. Signed-off-by:
-
Javier González authored
Remove dead function for manual sync. I/O Signed-off-by:
-
Javier González authored
If the namespace is unregistered before the LightNVM target is removed (e.g., on hot unplug) it is too late for the target to store any metadata on the device - any attempt to write to the device will fail. In this case, pass on a "gracefull teardown" flag to the target to let it know when this happens. In the case of pblk, we pad the open line (close all open chunks) to improve data retention. In the event of an ungraceful shutdown, avoid this part and just clean up. Signed-off-by:
-
Javier González authored
Do the check for the chunk state after making sure that the chunk type is supported. Fixes: 32ef9412 ("lightnvm: pblk: implement get log report chunk") Signed-off-by:
-
Javier González authored
Remove unnecessary argument on pblk_line_free() Signed-off-by:
-
Javier González authored
Call nvm_submit_io directly and remove an unnecessary indirection on the read path. Signed-off-by:
-
Javier González authored
Return a meaningful error when the sanity vector I/O check fails. Signed-off-by:
-
Javier González authored
When cleaning up buffer entries as we wrap up, their state should be "completed". If any of the entries is in "submitted" state, it means that something bad has happened. Trigger a warning immediately instead of waiting for the state flag to eventually be updated, thus hiding the issue. Signed-off-by:
-
Javier González authored
In the event of a mismatch between the read LBA and the metadata pointer reported by the device, improve the error message to be able to detect the offending physical address (PPA) mapped to the corrupted LBA. Signed-off-by:
-
Javier González authored
Check that the lba stored in the LBA metadata is correct in the GC path too. This requires a new helper function to check random reads in the vector read. Signed-off-by:
-
Javier González authored
Bad blocks can grow at runtime. Check that the number of valid blocks in a line are within the sanity threshold before allocating the line for new writes. Signed-off-by:
-
Javier González authored
In the event of a line failing to allocate, fail gracefully and stop the pipeline to avoid more write failing in the same place. Signed-off-by:
-
git://git.infradead.org/nvmeJens Axboe authored
Pull NVMe changes from Christoph: "Below is another set of NVMe updates for 4.18. Besides the usual bug fixes this includes more feature completness in terms of AEN and log page handling on the target." * 'nvme-4.18' of git://git.infradead.org/nvme: nvme: use the changed namespaces list log to clear ns data changed AENs nvme: mark nvme_queue_scan static nvme: submit AEN event configuration on startup nvmet: mask pending AENs nvmet: add AEN configuration support nvmet: implement the changed namespaces log nvmet: split log page implementation nvmet: add a new nvmet_zero_sgl helper nvme.h: add AEN configuration symbols nvme.h: add the changed namespace list log nvme.h: untangle AEN notice definitions nvmet: fix error return code in nvmet_file_ns_enable() nvmet: fix a typo in nvmet_file_ns_enable() nvme-fabrics: allow internal passthrough command on deleting controllers nvme-loop: add support for multiple ports nvme-pci: simplify __nvme_submit_cmd nvme-pci: Rate limit the nvme timeout warnings nvme: allow duplicate controller if prior controller being deleted
-
Christoph Hellwig authored
There is almost no shared logic, which leads to a very confusing code flow. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Damien Le Moal <damien.lemoal@wdc.com> Tested-by:
-
Christoph Hellwig authored
Both callers take just around so function call, so move it in. Also remove the now pointless blk_mq_sched_init wrapper. Signed-off-by:
-
Christoph Hellwig authored
Reported-by:
-
Christoph Hellwig authored
These are only used by the block core. Also move the declarations to block/blk.h. Reported-by:
-
Christoph Hellwig authored
No point in doing this in elevator_init. Signed-off-by:
-
Christoph Hellwig authored
Per section 5.2 we need to issue the corresponding log page to clear an AEN, so for a namespace data changed AEN we need to read the changed namespace list log. And once we read that log anyway we might as well use it to optimize the rescan. Signed-off-by:
Sagi Grimberg <sagi@grimberg.me>
-
Christoph Hellwig authored
And move it toward the top of the file to avoid a forward declaration. Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de>
-
Hannes Reinecke authored
We should register for AEN events; some law-abiding targets might not be sending us AENs otherwise. Signed-off-by:
Hannes Reinecke <hare@suse.com> [hch: slight cleanups] Signed-off-by:
-
Christoph Hellwig authored
Per section 5.2 of the NVMe 1.3 spec: "When the controller posts a completion queue entry for an outstanding Asynchronous Event Request command and thus reports an asynchronous event, subsequent events of that event type are automatically masked by the controller until the host clears that event. An event is cleared by reading the log page associated with that event using the Get Log Page command (see section 5.14)." Signed-off-by:
-
Christoph Hellwig authored
AEN configuration via the 'Get Features' and 'Set Features' admin command is mandatory, so we should be implemeting handling for it. Signed-off-by:
Daniel Verkamp <daniel.verkamp@intel.com>
-
Christoph Hellwig authored
Just keep a per-controller buffer of changed namespaces and copy it out in the get log page implementation. Signed-off-by:
-
Christoph Hellwig authored
Remove the common code to allocate a buffer and copy it into the SGL. Instead the two no-op implementations just zero the SGL directly, and the smart log allocates a buffer on its own. This prepares for the more elaborate ANA log page. Signed-off-by:
-
Christoph Hellwig authored
Zeroes the SGL in the payload. Signed-off-by:
-
Hannes Reinecke authored
Signed-off-by:
-
- 31 May, 2018 8 commits
-
-
Christoph Hellwig authored
Signed-off-by:
-
Christoph Hellwig authored
Stop including the event type in the definitions for the notice type. Signed-off-by:
-
Wei Yongjun authored
Fix to return error code -ENOMEM from the memory alloc fail error handling case instead of 0, as done elsewhere in this function. Fixes: d5eff33e ("nvmet: add simple file backed ns support") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.e> Signed-off-by:
-
Wei Yongjun authored
Fix a typo in nvmet_file_ns_enable(). Fixes: d5eff33e ("nvmet: add simple file backed ns support") Signed-off-by:
-
Christoph Hellwig authored
Without this we can't cleanly shut down. Based on analysis an an earlier patch from Hannes Reinecke. Fixes: bb06ec31 ("nvme: expand nvmf_check_if_ready checks") Reported-by:
Hannes Reinecke <hare@suse.de> Tested-by:
James Smart <james.smart@broadcom.com>
-
Davide Sapienza authored
BFQ can deem a bfq_queue as soft real-time only if the queue - periodically becomes completely idle, i.e., empty and with no still-outstanding I/O request; - after becoming idle, gets new I/O only after a special reference time soft_rt_next_start. In this respect, after commit "block, bfq: consider also past I/O in soft real-time detection", the value of soft_rt_next_start can never decrease. This causes a problem with the following special updating case for soft_rt_next_start: to prevent queues that are not completely idle to be wrongly detected as soft real-time (when they become non-empty again), soft_rt_next_start is temporarily set to infinity for empty queues with still outstanding I/O requests. But, if such an update is actually performed, then, because of the above commit, soft_rt_next_start will be stuck at infinity forever, and the queue will have no more chance to be considered soft real-time. On slow systems, this problem does cause actual soft real-time applications to be occasionally not detected as such. This commit addresses this issue by eliminating the pushing of soft_rt_next_start to infinity, and by changing the way non-empty queues are prevented from being wrongly detected as soft real-time. Simply, a queue that becomes non-empty again can now be detected as soft real-time only if it has no outstanding I/O request. Signed-off-by:
Davide Sapienza <sapienza.dav@gmail.com> Signed-off-by:
Paolo Valente <paolo.valente@linaro.org> Signed-off-by:
-
Davide Sapienza authored
The maximum possible duration of the weight-raising period for interactive applications is limited to 13 seconds, as this is the time needed to load the largest application that we considered when tuning weight raising. Unfortunately, in such an evaluation, we did not consider the case of very slow virtual machines. For example, on a QEMU/KVM virtual machine - running in a slow PC; - with a virtual disk stacked on a slow low-end 5400rpm HDD; - serving a heavy I/O workload, such as the sequential reading of several files; mplayer takes 23 seconds to start, if constantly weight-raised. To address this issue, this commit conservatively sets the upper limit for weight-raising duration to 25 seconds. Signed-off-by:
-
Paolo Valente authored
BFQ computes the duration of weight raising for interactive applications automatically, using some reference parameters. In particular, BFQ uses the best durations (see comments in the code for how these durations have been assessed) for two classes of systems: slow and fast ones. Examples of slow systems are old phones or systems using micro HDDs. Fast systems are all the remaining ones. Using these parameters, BFQ computes the actual duration of the weight raising, for the system at hand, as a function of the relative speed of the system w.r.t. the speed of a reference system, belonging to the same class of systems as the system at hand. This slow vs fast differentiation proved to be useful in the past, but happens to have little meaning with current hardware. Even worse, it does cause problems in virtual systems, where the speed of the system can vary frequently, and so widely to just confuse the class-detection mechanism, and, as we have verified experimentally, to cause BFQ to compute non-sensical weight-raising durations. This commit addresses this issue by removing the slow class and the class-detection mechanism. Signed-off-by:
-
