----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.csiden.org/r/112/#review649 -----------------------------------------------------------
Ship it! No blockers, just one nit request. usr/src/uts/common/fs/zfs/arc.c (line 4739) <https://reviews.csiden.org/r/112/#comment506> Nit: generally following Matt's general philosophy of helping the compiler be our friend for safety, if we don't use write_psize until this loop, might we defer initialization, if not declaration, until this point? usr/src/uts/common/fs/zfs/arc.c (lines 4802 - 4803) <https://reviews.csiden.org/r/112/#comment507> - Bayard Bell On Oct. 8, 2014, 1:57 p.m., Justin Gibbs wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.csiden.org/r/112/ > ----------------------------------------------------------- > > (Updated Oct. 8, 2014, 1:57 p.m.) > > > Review request for OpenZFS Developer Mailing List, Matthew Ahrens and Saso > Kiselkov. > > > Repository: illumos-gate > > > Description > ------- > > If we don't account for that, then we might end up overwriting disk > area of buffers that have not been evicted yet, because l2arc_evict > operates in terms of disk addresses. > > The discrepancy between the write size calculation and the actual increment > to l2ad_hand was introduced in > commit e14bb3258d05c1b1077e2db7cf77088924e56919 > > Also, consistently use asize / a_sz for the allocated size, psize / p_sz > for the physical size. Where the latter accounts for possible size > reduction because of compression, whereas the former accounts for possible > size expansion because of alignment requirements. > > The code still assumes that either underlying storage subsystems or > hardware is able to do read-modify-write when an L2ARC buffer size is > not a multiple of a disk's block size. This is true for 4KB sector disks > that provide 512B sector emulation, but may not be true in general. > In other words, we currently do not have any code to make sure that > an L2ARC buffer, whether compressed or not, which is used for physical I/O > has a suitable size. > > > Diffs > ----- > > usr/src/uts/common/fs/zfs/arc.c 69d16af3b669458e3937fe0c6a4d91755bc6e2a7 > > Diff: https://reviews.csiden.org/r/112/diff/ > > > Testing > ------- > > > Thanks, > > Justin Gibbs > >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
