This patch series adds a new ioctl TREE_SEARCH_V2 with which we could store the results in a varying buffer. With that even items larger than 3992 bytes or a large amount of items can be returned. This is the case e.g. for some EXTENT_CSUM items, which could have a size up to 16k. I had a few questions: Which value should I assign to TREE_SEARCH_V2? * Chosen value is ok [1]. Should we limit the buffer size? * David suggested [1] a minimum of 64k, I've chosen a cap of 16M. What about documentation? * I documented the new struct in the header file. Gerhard [1] http://article.gmane.org/gmane.comp.file-systems.btrfs/32060 Changelog RFCv3 * introduced read_extent_buffer_to_user * direct copy to user without intermediate buffer * use local variables for args * fixed wrong error code * removed unused var check * fixed minor style issues * return needed buffer to userspace on EOVERFLOW RFCv2 * fixed a build bug caused by using a wrong patch * added a patch to expand a buffer lifetime -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
