> 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).
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.
- 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
