> On Nov. 30, 2014, 9:02 p.m., Matthew Ahrens wrote: > > You will need to test on illumos too, at least some minimal sanity > > checking. Let me know if you need help with that. > > Andriy Gapon wrote: > I am still not set up for illumos testing :-( > So I must ask for your help again. Thank you!
Andriy, I'll allocate some time to test this on illumos/DelphixOS. Is there any specific test you need me to run? or just the usual pre-commit regression tests? - Prakash ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.csiden.org/r/112/#review378 ----------------------------------------------------------- On Oct. 8, 2014, 1:57 p.m., Andriy Gapon 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, > > Andriy Gapon > >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
