MFV r319950: 5220 L2ARC does not support devices that do not provide 512B access
FreeBSD note: the actual change has been in FreeBSD since r297848. This
commit accounts for integration of that change with subsequent changes,
especially r320156 (MFV of r318946) and r314274.
illumos/illumos-gate@403a8da73c
403a8da73c
https://www.illumos.org/issues/5220
There are disk devices that have logical sector size larger than 512B, for
example 4KB. That is, their physical sector size is larger than 512B and they
do not provide emulation for 512B sector sizes. For such devices both a data
offset and a data size must be properly aligned. L2ARC should arrange that
because it uses physical I/O.
zio_vdev_io_start() performs a necessary transformation if io_size is not
aligned to vdev_ashift, but that is done only for logical I/O. Something
similar should be done in L2ARC code.
* a temporary write buffer should be allocated if the original buffer is
not going to be compressed and its size is not aligned
* size of a temporary compression buffer should be ashift aligned
* for the reads, if a size of a target buffer is not sufficiently large and
it is not aligned then a temporary read buffer should be allocated
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Dan Kimmel <dan.kimmel@delphix.com>
Reviewed by: Saso Kiselkov <saso.kiselkov@nexenta.com>
Approved by: Dan McDonald <danmcd@joyent.com>
Author: Andriy Gapon <avg@FreeBSD.org>
MFC after: 3 weeks
This commit is contained in:
parent
8c2cf18ddb
commit
c93bff419b
@ -1343,7 +1343,7 @@ typedef struct l2arc_read_callback {
|
||||
blkptr_t l2rcb_bp; /* original blkptr */
|
||||
zbookmark_phys_t l2rcb_zb; /* original bookmark */
|
||||
int l2rcb_flags; /* original flags */
|
||||
void *l2rcb_abd; /* temporary buffer */
|
||||
abd_t *l2rcb_abd; /* temporary buffer */
|
||||
} l2arc_read_callback_t;
|
||||
|
||||
typedef struct l2arc_write_callback {
|
||||
@ -7485,8 +7485,13 @@ l2arc_write_buffers(spa_t *spa, l2arc_dev_t *dev, uint64_t target_sz)
|
||||
* Normally the L2ARC can use the hdr's data, but if
|
||||
* we're sharing data between the hdr and one of its
|
||||
* bufs, L2ARC needs its own copy of the data so that
|
||||
* the ZIO below can't race with the buf consumer. To
|
||||
* ensure that this copy will be available for the
|
||||
* the ZIO below can't race with the buf consumer.
|
||||
* Another case where we need to create a copy of the
|
||||
* data is when the buffer size is not device-aligned
|
||||
* and we need to pad the block to make it such.
|
||||
* That also keeps the clock hand suitably aligned.
|
||||
*
|
||||
* To ensure that the copy will be available for the
|
||||
* lifetime of the ZIO and be cleaned up afterwards, we
|
||||
* add it to the l2arc_free_on_write queue.
|
||||
*/
|
||||
|
Loading…
Reference in New Issue
Block a user