> On March 5, 2015, 7:41 p.m., Josef 'Jeff' Sipek wrote:
> > usr/src/man/man1m/zfs.1m, line 1007
> > <https://reviews.csiden.org/r/166/diff/4/?file=14326#file14326line1007>
> >
> >     Isn't this true for both lzjb & lz4?  I guess I'm not quite seeing the 
> > value of this sentence.

There needs to be a description associated with each compression algorithm.  I 
just reused the existing text.  If you can provide better description text, I'd 
be happy to include it.


- Justin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.csiden.org/r/166/#review547
-----------------------------------------------------------


On March 5, 2015, 5:24 a.m., Justin Gibbs wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.csiden.org/r/166/
> -----------------------------------------------------------
> 
> (Updated March 5, 2015, 5:24 a.m.)
> 
> 
> Review request for OpenZFS Developer Mailing List.
> 
> 
> Bugs: 5661
>     https://www.illumos.org/projects/illumos-gate//issues/5661
> 
> 
> Repository: illumos-gate
> 
> 
> Description
> -------
> 
> Make lz4 the default compression algrithm for datasets with                   
>    
> the "compression=on" property setting.  lzjb will be used if the              
>    
> pool does not have "feature@lz4_compress" enabled.
> 
> uts/common/fs/zfs/sys/zio.h:
>       Replace ZIO_COMPRESS_ON_VALUE with
>       ZIO_COMPRESS_LEGACY_ON_VALUE and ZIO_COMPRESS_LZ4_ON_VALUE.
>       The former is used for pools without "feature@lz4_compress"
>       enabled.
> 
>       Allow ZIO_COMPRESS_ON on bootable datasets without
>       restriction to certain values of (the now removed)
>       ZIO_COMPRESS_ON_VALUE constant.  The boot loader
>       knows how to decompress both lzjb and lz4, the two
>       types of compression that ZIO_COMPRESS_ON can mean.
>       The loader also does not write data, and existing
>       blkptrs have the compression type explicitly listed
>       (ZIO_COMPRESS_ON never hits the media), making
>       ZIO_COMPRESS_ON bootfs safe.
> 
> uts/common/fs/zfs/dmu.c:
> uts/common/fs/zfs/dmu_objset.c:
> uts/common/fs/zfs/sys/zio.h:
> uts/common/fs/zfs/zio_compress.c:
>       Pass the spa into zio_compress_select() so that
>       enabled spa features can be considered with selecting
>       a compression algorithm.
> 
> uts/common/fs/zfs/dmu_objset.c:
> uts/common/fs/zfs/zio_compress.c:
>     Historically, callers of zio_compress_select()
>     converted a parent value of ZIO_COMPRESS_ON to
>     ZIO_COMPRESS_ON_VALUE (on -> lzjb).  This made
>     it impossible for zio_compress_select() to
>     differentiate between a user explicitly requesting
>     lzjb or the default compression algorithm.  Allow
>     the parent/inherited value to be expressed as
>     ZIO_COMPRESS_ON and convert it to the appropriate
>     default compression algorithm within
>     zio_compress_select().
> 
> uts/common/fs/zfs/dmu.c:
>       In dmu_write_policy(), rather than duplicate logic
>       which is now in zio_compress_select(), use
>       zio_compress_select() to determine the correct
>       compression algorithm to use for metadata.
> 
> uts/common/fs/zfs/dmu_objset.c:
>       Allow the MOS to use the default compression algorithm
>       rather than hard code lzjb.
> 
> 
> Diffs
> -----
> 
>   usr/src/uts/common/fs/zfs/zio_compress.c 
> 0d77f246c4a755cef5bbdc1e9cd3b34882b01730 
>   usr/src/uts/common/fs/zfs/sys/zio.h 
> 71bb6b96a01c51437cd5c6622e404531b5e8de17 
>   usr/src/uts/common/fs/zfs/dmu_objset.c 
> 8593e2c94f6cb5e5b3866f5763f6230e25294716 
>   usr/src/uts/common/fs/zfs/dmu.c c541e04d54297243c9d6a342b7a8df742e8d7ed2 
>   usr/src/man/man1m/zfs.1m b679b77ba4e58fbeaf7a63052e49398ca2c80212 
> 
> Diff: https://reviews.csiden.org/r/166/diff/
> 
> 
> Testing
> -------
> 
> ztest via zloop on illumos.  ZFS test suite on FreeBSD and illumos.
> 
> 
> Thanks,
> 
> Justin Gibbs
> 
>

_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer

Reply via email to