> 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! > > Prakash Surya wrote: > 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 Surya wrote: > Since I haven't heard back, I'm going to go ahead and push this through > our regression tests. > > This patch didn't apply cleanly on the latest illumos-gate code (git sha: > 3d1d816) so I rolled back to a previous version (git sha: bafd1f1) and > applied this patch on top of that. I think this patch is now conflicting with > George's work that went in on Dec. 6th (git sha: 7adb730), although I didn't > double check that. > > Anyways, I have this patch applied on top of bafd1f1 running through our > internal regression tests: http://jenkins/job/zfs-precommit/1398/ (useless > link, unless you're within the Delphix network). > > Prakash Surya wrote: > This failed a number of tests in the zfs test suite: > > > > FAIL rsend/rsend_009_pos [no bug found] > > FAIL cli_root/zfs_create/zfs_create_008_neg [no bug found] > > FAIL link_count/link_count_001 [no bug found] > > FAIL zvol/zvol_swap/zvol_swap_004_pos [no bug found] > > FAIL rootpool/rootpool_002_neg [no bug found] > > FAIL cli_root/zfs_mount/zfs_mount_009_neg [no bug found] > > FAIL mmap/mmap_write_001_pos [no bug found] > > FAIL cli_root/zpool_create/zpool_create_023_neg [no bug found] > > > > I've kicked off another test run just in case these were due to internal > > infrastructure issues and not the patch: > > > > http://jenkins/job/zfs-precommit/1407/ > > > > If this next run fails in a similar fashion, we'll need to debug the > > failures and ensure they pass prior to landing.
After looking closer, these tests are all failing on illumos' HEAD, so they're not introduced by this patch. Everything else looks good from the build and 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
