{"push_id":1608620927,"size":11,"distinct_size":11,"ref":"refs/heads/SVN/vendor/illumos","head":"5a498feee4b9cfb0fd775381dccf10514b4d2520","before":"68b6ab4130e167196d2e1ad307ab8c361e0d2af0","commits":[{"sha":"25af61e83dd3ae79401f4359b910476334d11bad","author":{"name":"avg","email":"b24d11afb16644e3ff52469bebd6e863d3282d4e@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f"},"message":"6876 Stack corruption after importing a pool with a too-long name\n\nillumos/illumos-gate@c971037baa5d64dfecf6d87ed602fc3116ebec41\nhttps://github.com/illumos/illumos-gate/commit/c971037baa5d64dfecf6d87ed602fc3116ebec41\n\nhttps://www.illumos.org/issues/6876\n  Calling dsl_dataset_name on a dataset with a 256 byte buffer is asking for\n  trouble. We should check every dataset on import, using a 1024 byte buffer and\n  checking each time to see if the dataset's new name is longer than 256 bytes.\n\nReviewed by: Prakash Surya <prakash.surya@delphix.com>\nReviewed by: Dan Kimmel <dan.kimmel@delphix.com>\nReviewed by: George Wilson <george.wilson@delphix.com>\nReviewed by: Yuri Pankov <yuri.pankov@nexenta.com>\nApproved by: Richard Lowe <richlowe@richlowe.net>\nAuthor: Paul Dagnelie <pcd@delphix.com>\n\n\ngit-svn-id: https://svn.freebsd.org/base/vendor/illumos/dist@302642 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","distinct":true,"url":"https://api.github.com/repos/mat813/freebsd/commits/25af61e83dd3ae79401f4359b910476334d11bad"},{"sha":"4a821122b8e1fb8b28b5c29898da6422eeb7a1e7","author":{"name":"avg","email":"b24d11afb16644e3ff52469bebd6e863d3282d4e@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f"},"message":"6902 speed up listing of snapshots if requesting name only and sorting by name\n\nillumos/illumos-gate@0d8fa8f8eba3ea46bc79d73445009505d1dd5d7d\nhttps://github.com/illumos/illumos-gate/commit/0d8fa8f8eba3ea46bc79d73445009505d1dd5d7d\n\nhttps://www.illumos.org/issues/6902\n  pjd has authored and commited a patch in Jan 21, 2012 that substanially speeds\n  up zfs snapshot listing if requesting only the name property and sorting by\n  name.\n  In this special case, the snapshot properties do not need to be loaded. This\n  code has been adopted by zfsonlinux on May 29, 2012.\n  Commit message from pjd:\n       Dramatically optimize listing snapshots when user requests only\n       snapshot\n       names and wants to sort them by name, ie. when executes:\n          1. zfs list -t snapshot -o name -s name\n       Because only name is needed we don't have to read all snapshot\n       properties.\n       Below you can find how long does it take to list 34509 snapshots from\n       a single\n       disk pool before and after this change with cold and warm cache:\n       before:\n          1. time zfs list -t snapshot -o name -s name > /dev/null\n             cold cache: 525s\n             warm cache: 218s\n       after:\n          1. time zfs list -t snapshot -o name -s name > /dev/null\n             cold cache: 1.7s\n             warm cache: 1.1s\n  References:\n  http://svnweb.freebsd.org/base?view=revision&revision=230438\n  https://github.com/freebsd/freebsd/commit/8e3e9863\n  https://github.com/zfsonlinux/zfs/commit/0cee2406\n\nReviewed by: Matthew Ahrens <mahrens@delphix.com>\nReviewed by: Pawel Dawidek <pjd@freebsd.org>\nReviewed by: Brian Behlendorf <behlendorf1@llnl.gov>\nApproved by: Garrett D'Amore <garrett@damore.org>\nAuthor: Martin Matuska <martin@matuska.org>\n\n\ngit-svn-id: https://svn.freebsd.org/base/vendor/illumos/dist@302643 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","distinct":true,"url":"https://api.github.com/repos/mat813/freebsd/commits/4a821122b8e1fb8b28b5c29898da6422eeb7a1e7"},{"sha":"be62b65c6ac0705b8f5cc9fa2790f3dbcb7aaef6","author":{"name":"avg","email":"b24d11afb16644e3ff52469bebd6e863d3282d4e@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f"},"message":"6111 zfs send should ignore datasets created after the ending snapshot\n\nillumos/illumos-gate@4a20c933b148de8a1c1d3538391c64284e636653\nhttps://github.com/illumos/illumos-gate/commit/4a20c933b148de8a1c1d3538391c64284e636653\n\nhttps://www.illumos.org/issues/6111\n  If you create a zfs child folder, zfs send returns an error when a recursive\n  incremental send is done between two snapshots made prior to the folder\n  creation.\n  The problem can be reproduced with the following steps.\n  root@zfs:/# zfs create pool/test\n  root@zfs:/# zfs snapshot pool/test@snap1\n  root@zfs:/# zfs snapshot pool/test@snap2\n  root@zfs:/# zfs create pool/test/child\n  root@zfs:/# zfs send -R -I pool/test@snap1 pool/test@snap2 > /dev/null\n  WARNING: could not send pool/test/child@snap2: does not exist\n  WARNING: could not send pool/test/child@snap2: does not exist\n  root@zfs:/# echo $?\n  1\n  root@zfs:/# zfs snapshot -r pool/test@snap3\n  root@zfs:/# zfs send -R -I pool/test@snap1 pool/test@snap3 > /dev/null\n  root@zfs:/# echo $?\n  0\n  root@zfs:/# zfs send -R -I pool/test@snap2 pool/test@snap3 > /dev/null\n  root@zfs:/# echo $?\n  0\n  Since pool/test/child was created after snap2, zfs send should not expect snap2\n  to be in pool/test/child when doing a recursive send. It should examine the\n  compare the creation time of the snapshot and each child folder to decide if\n  the folder will be sent. The next incremental send between snap2 and snap3\n  would properly create the child folder and snap3 which first appears in the\n  child folder.\n  The problem is identical if '-i' is used instead of '-I'.\n\nReviewed by: Alex Aizman alex.aizman@nexenta.com\nReviewed by: Alek Pinchuk alek.pinchuk@nexenta.com\nReviewed by: Roman Strashkin roman.strashkin@nexenta.com\nReviewed by: Matthew Ahrens <mahrens@delphix.com>\nReviewed by: Paul Dagnelie <pcd@delphix.com>\nApproved by: Garrett D'Amore <garrett@damore.org>\nAuthor: Alex Deiter <alex.deiter@nexenta.com>\n\n\ngit-svn-id: https://svn.freebsd.org/base/vendor/illumos/dist@302653 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","distinct":true,"url":"https://api.github.com/repos/mat813/freebsd/commits/be62b65c6ac0705b8f5cc9fa2790f3dbcb7aaef6"},{"sha":"9bd6aebeb3158afa6098fd6a6cd174a79c6859ce","author":{"name":"avg","email":"b24d11afb16644e3ff52469bebd6e863d3282d4e@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f"},"message":"6879 incorrect endianness swap for drr_spill.drr_length in libzfs_sendrecv.c\n\nillumos/illumos-gate@20fea7a47472aceb64d3ed48cc2a3ea268bc4795\nhttps://github.com/illumos/illumos-gate/commit/20fea7a47472aceb64d3ed48cc2a3ea268bc4795\n\nhttps://www.illumos.org/issues/6879\n  In libzfs_sendrecv, there's a typo:\n  case DRR_SPILL:\n              if (byteswap) {\n                  drr->drr_u.drr_write.drr_length =\n                      BSWAP_64(drr->drr_u.drr_spill.drr_length);\n              }\n  Instead of drr_write.drr_length, we should be assigning the result of the\n  byteswap to drr_spill.drr_length.\n\nReviewed by: Matthew Ahrens <mahrens@delphix.com>\nReviewed by: Paul Dagnelie <pcd@delphix.com>\nApproved by: Robert Mustacchi <rm@joyent.com>\nAuthor: Dan Kimmel <dan.kimmel@delphix.com>\n\n\ngit-svn-id: https://svn.freebsd.org/base/vendor/illumos/dist@302654 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","distinct":true,"url":"https://api.github.com/repos/mat813/freebsd/commits/9bd6aebeb3158afa6098fd6a6cd174a79c6859ce"},{"sha":"5e5482cacad870c2114fe4357b5c10d839295c28","author":{"name":"avg","email":"b24d11afb16644e3ff52469bebd6e863d3282d4e@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f"},"message":"6873 zfs_destroy_snaps_nvl leaks errlist\n\nillumos/illumos-gate@4cde22c29999ffb907ca39d2ebd512812f7e5168\nhttps://github.com/illumos/illumos-gate/commit/4cde22c29999ffb907ca39d2ebd512812f7e5168\n\nhttps://www.illumos.org/issues/6873\n  lzc_destroy_snaps() returns an nvlist in errlist.\n  zfs_destroy_snaps_nvl() should nvlist_free() it before returning.\n\nReviewed by: Matthew Ahrens <mahrens@delphix.com>\nReviewed by: Paul Dagnelie <pcd@delphix.com>\nApproved by: Dan McDonald <danmcd@omniti.com>\nAuthor: Chris Williamson <chris.williamson@delphix.com>\n\n\ngit-svn-id: https://svn.freebsd.org/base/vendor/illumos/dist@302655 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","distinct":true,"url":"https://api.github.com/repos/mat813/freebsd/commits/5e5482cacad870c2114fe4357b5c10d839295c28"},{"sha":"1a2d5f298258108494f77952e9a0eeb6d8b5e9ff","author":{"name":"avg","email":"b24d11afb16644e3ff52469bebd6e863d3282d4e@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f"},"message":"5813 zfs_setprop_error(): Handle errno value E2BIG.\n\nillumos/illumos-gate@6fdcb3d1c2baae812d9cbce37b41469b924efd90\nhttps://github.com/illumos/illumos-gate/commit/6fdcb3d1c2baae812d9cbce37b41469b924efd90\n\nhttps://www.illumos.org/issues/5813\n  Lets pull in this patch from freebsd:\n  http://svnweb.freebsd.org/base?view=revision&revision=271764\n  zfs_setprop_error(): Handle errno value E2BIG.\n  This errno value is emitted by dsl_props_set_check() in\n  sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_prop.c, and\n  is used to mean that the property value is too long. For the record,\n  the maximum length is ZAP_MAXVALUELEN, which is 8*1024 bytes.\n  Instead of claiming an unknown error (and abort()ing), provide\n  something more specific to the scenario involved. As far as I\n  can tell, E2BIG is not emitted for any other scenario.\n  MFC after: 1 week\n  Sponsored by: Spectra Logic\n  Affects: All ZFS versions starting 27 Feb 2009 (illumos ccba0801)\n  This change modified the value returned by\n  dsl_props_set_check(), so that it can distinguish between\n  a name that's too long and a value that's too long, but\n  libzfs was not updated accordingly.\n  MFSpectraBSD: r1051499 on 2014/03/28 11:07:59\n\nReviewed by: Paul Dagnelie <paul.dagnelie@delphix.com>\nReviewed by: Matthew Ahrens <mahrens@delphix.com>\nReviewed by: Prakash Surya <prakash.surya@delphix.com>\nReviewed by: Richard Elling <richard.elling@richardelling.com>\nApproved by: Garrett D'Amore <garrett@damore.org>\nAuthor: Will Andrews <will@freebsd.org>\n\n\ngit-svn-id: https://svn.freebsd.org/base/vendor/illumos/dist@302656 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","distinct":true,"url":"https://api.github.com/repos/mat813/freebsd/commits/1a2d5f298258108494f77952e9a0eeb6d8b5e9ff"},{"sha":"da405ffa20e45045061c218111fcfd6e4b4919f2","author":{"name":"avg","email":"b24d11afb16644e3ff52469bebd6e863d3282d4e@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f"},"message":"4521 zfstest is trying to execute evil \"zfs unmount -a\"\n\nillumos/illumos-gate@8808ac5dae118369991f158b6ab736cb2691ecde\nhttps://github.com/illumos/illumos-gate/commit/8808ac5dae118369991f158b6ab736cb2691ecde\n\nhttps://www.illumos.org/issues/4521\n  zfstest is trying to execute evil \"zfs unmount -a\", which fails (fortunately,\n  as it would otherwise leave me with my ~ missing):\n  03:44:11.86 cannot unmount '/export/home/yuri': Device busy cannot unmount '/\n  export/home': Device busy\n  03:44:11.86 ERROR: /usr/sbin/zfs unmount -a exited 1\n  This affects, at least, zfs_mount_009_neg and zfs_mount_all_001_pos, both\n  failing on that step. The pool containing the /export/home hierarchy is\n  included in KEEP variable, but it doesn't seem to affect anything here.\n\nReviewed by: Andriy Gapon <avg@FreeBSD.org>\nReviewed by: Dan McDonald <danmcd@omniti.com>\nReviewed by: Matthew Ahrens <mahrens@delphix.com>\nReviewed by: John Kennedy <john.kennedy@delphix.com>\nApproved by: Robert Mustacchi <rm@joyent.com>\nAuthor: Yuri Pankov <yuri.pankov@nexenta.com>\n\n\ngit-svn-id: https://svn.freebsd.org/base/vendor/illumos/dist@302657 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","distinct":true,"url":"https://api.github.com/repos/mat813/freebsd/commits/da405ffa20e45045061c218111fcfd6e4b4919f2"},{"sha":"6a8f5905b8b9f9b886e0f47021017415193d142a","author":{"name":"avg","email":"b24d11afb16644e3ff52469bebd6e863d3282d4e@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f"},"message":"6872 zfs libraries should not allow uninitialized variables\n\nillumos/illumos-gate@f83b46baf98d276f5f84fa84c8b461f412ac1f5e\nhttps://github.com/illumos/illumos-gate/commit/f83b46baf98d276f5f84fa84c8b461f412ac1f5e\n\nhttps://www.illumos.org/issues/6872\n  We compile the zfs libraries with -Wno-uninitialized. We should remove\n  this. Change makefiles, fix new warnings, fix pbchk errors.\n\nReviewed by: Dan Kimmel <dan.kimmel@delphix.com>\nReviewed by: George Wilson <george.wilson@delphix.com>\nReviewed by: Prakash Surya <prakash.surya@delphix.com>\nReviewed by: Yuri Pankov <yuri.pankov@nexenta.com>\nApproved by: Robert Mustacchi <rm@joyent.com>\nAuthor: Paul Dagnelie <pcd@delphix.com>\n\n\ngit-svn-id: https://svn.freebsd.org/base/vendor/illumos/dist@302658 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","distinct":true,"url":"https://api.github.com/repos/mat813/freebsd/commits/6a8f5905b8b9f9b886e0f47021017415193d142a"},{"sha":"34204f49bd8023c08db31a88a5c1e476dc9663e2","author":{"name":"avg","email":"b24d11afb16644e3ff52469bebd6e863d3282d4e@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f"},"message":"6931 lib/libzfs: cleanup gcc warnings\n\nillumos/illumos-gate@88f61dee20b358671b1b643e9d1dbf220a1d69be\nhttps://github.com/illumos/illumos-gate/commit/88f61dee20b358671b1b643e9d1dbf220a1d69be\n\nhttps://www.illumos.org/issues/6931\n  need cleanup:\n  CERRWARN += -_gcc=-Wno-switch\n  CERRWARN += -_gcc=-Wno-parentheses\n  CERRWARN += -_gcc=-Wno-unused-function\n\nReviewed by: Matthew Ahrens <mahrens@delphix.com>\nApproved by: Robert Mustacchi <rm@joyent.com>\nAuthor: Igor Kozhukhov <ikozhukhov@gmail.com>\n\n\ngit-svn-id: https://svn.freebsd.org/base/vendor/illumos/dist@302659 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","distinct":true,"url":"https://api.github.com/repos/mat813/freebsd/commits/34204f49bd8023c08db31a88a5c1e476dc9663e2"},{"sha":"b648688ad12da30efcc34ec6f76165c8e53ee9a8","author":{"name":"avg","email":"b24d11afb16644e3ff52469bebd6e863d3282d4e@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f"},"message":"6314 buffer overflow in dsl_dataset_name\n\nillumos/illumos-gate@9adfa60d484ce2435f5af77cc99dcd4e692b6660\nhttps://github.com/illumos/illumos-gate/commit/9adfa60d484ce2435f5af77cc99dcd4e692b6660\n\nhttps://www.illumos.org/issues/6314\n  Callers of dsl_dataset_name pass a buffer of size ZFS_MAXNAMELEN, but\n  dsl_dataset_name copies the datasets' name PLUS the snapshot name to it,\n  resulting in a max of 2 * ZFS_MAXNAMELEN + '@'.\n\nReviewed by: George Wilson <george.wilson@delphix.com>\nReviewed by: Prakash Surya <prakash.surya@delphix.com>\nReviewed by: Igor Kozhukhov <ikozhukhov@gmail.com>\nApproved by: Dan McDonald <danmcd@omniti.com>\nAuthor: Matthew Ahrens <mahrens@delphix.com>\n\n\ngit-svn-id: https://svn.freebsd.org/base/vendor/illumos/dist@302660 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","distinct":true,"url":"https://api.github.com/repos/mat813/freebsd/commits/b648688ad12da30efcc34ec6f76165c8e53ee9a8"},{"sha":"5a498feee4b9cfb0fd775381dccf10514b4d2520","author":{"name":"avg","email":"b24d11afb16644e3ff52469bebd6e863d3282d4e@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f"},"message":"6447 handful of nvpair cleanups\n\nillumos/illumos-gate@759e89be359f2af635e4122d147df56bce948773\nhttps://github.com/illumos/illumos-gate/commit/759e89be359f2af635e4122d147df56bce948773\n\nhttps://www.illumos.org/issues/6447\n  I got a patch from someone who uses nvpair code outside of illumos. It fixes a\n  couple of gcc warnings/bugs for him.\n     1. silence uninitialized use warnings\n     2. add parentheses around assignment used as truth value\n     3. fix printf format specifier (ll is for integers only)\n     4. strstr, strspn, strcspn, and strcmp are declared in string.h, not\n        strings.h.\n     5. avoid scanning integer into boolean variable\n\nReviewed by: Josef 'Jeff' Sipek <jeffpc@josefsipek.net>\nReviewed by: Andy Stormont <astormont@racktopsystems.com>\nReviewed by: Garrett D'Amore <garrett@damore.org>\nApproved by: Robert Mustacchi <rm@joyent.com>\nAuthor: Steve Dougherty <sdougherty@barracuda.com>\n\n\ngit-svn-id: https://svn.freebsd.org/base/vendor/illumos/dist@302662 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","distinct":true,"url":"https://api.github.com/repos/mat813/freebsd/commits/5a498feee4b9cfb0fd775381dccf10514b4d2520"}]}
{"actor":{"display_login":"mat813"}}