{"push_id":687743092,"size":1,"distinct_size":1,"ref":"refs/heads/zfs_master_20.03.2015_2129+3115_WIP_clean","head":"db0100773414486c20c427b484001d34fe278f62","before":"84029b28c1a39c9cd530334c425ddd5b7d05d2b8","commits":[{"sha":"db0100773414486c20c427b484001d34fe278f62","author":{"email":"97e77871b5fcc4941bebceb4338c97c1fd149f8c@freebsd.org","name":"Andriy Gapon"},"message":"[RFC, discussion, feedback] account for ashift when choosing buffers to be written to l2arc device\n\nIf we don't account for that, then we might end up overwriting disk\narea of buffers that have not been evicted yet, because l2arc_evict\noperates in terms of disk addresses.\n\nThe discrepancy between the write size calculation and the actual increment\nto l2ad_hand was introduced in\ncommit e14bb3258d05c1b1077e2db7cf77088924e56919\n\nAlso, consistently use asize / a_sz for the allocated size, psize / p_sz\nfor the physical size.  Where the latter accounts for possible size\nreduction because of compression, whereas the former accounts for possible\nsize expansion because of alignment requirements.\n\nThe code still assumes that either underlying storage subsystems or\nhardware is able to do read-modify-write when an L2ARC buffer size is\nnot a multiple of a disk's block size.  This is true for 4KB sector disks\nthat provide 512B sector emulation, but may not be true in general.\nIn other words, we currently do not have any code to make sure that\nan L2ARC buffer, whether compressed or not, which is used for physical I/O\nhas a suitable size.\n\nmodified to account for the changes of\n\nand\n\nIllumos - 5701 zpool list reports incorrect \"alloc\" value for cache devices","distinct":true,"url":"https://api.github.com/repos/kernelOfTruth/zfs/commits/db0100773414486c20c427b484001d34fe278f62"}]}