> On April 9, 2015, 4:04 a.m., Bayard Bell wrote: > > usr/src/uts/common/fs/zfs/arc.c, line 4740 > > <https://reviews.csiden.org/r/112/diff/1/?file=10378#file10378line4740> > > > > 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?
this particular function seems to follow the convention of placing all variable declarations before actual code, so I am not if it's really worthwhile to make an exception for a single variable - Andriy ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.csiden.org/r/112/#review649 ----------------------------------------------------------- On Oct. 8, 2014, 4: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, 4: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
