Return-Path: <tiff-bounces@lists.osgeo.org>
Delivered-To: filtered@awaresystems.be
Received: from mx1.pub.mailpod8-cph3.one.com ([10.27.38.11])
	by mailstorage22.cst.mailpod8-cph3.one.com with LMTP id OMxCIj+Jn12/DwAAwT5NuQ
	for <filtered@awaresystems.be>; Thu, 10 Oct 2019 19:40:47 +0000
X-HalOne-ID: da2c833f-eb95-11e9-b848-98039b0f6c32
Received: from lists.osgeo.org (osgeo6.osgeo.osuosl.org [140.211.15.3])
	by mx1.pub.mailpod8-cph3.one.com (Halon) with ESMTPS
	id da2c833f-eb95-11e9-b848-98039b0f6c32;
	Thu, 10 Oct 2019 19:40:46 +0000 (UTC)
Received: from osgeo6.osgeo.osuosl.org (localhost [127.0.0.1])
	by lists.osgeo.org (Postfix) with ESMTP id 8C6466138C9D;
	Thu, 10 Oct 2019 12:40:43 -0700 (PDT)
Received: from smtp.simplesystems.org (smtp.simplesystems.org [65.66.246.90])
 by lists.osgeo.org (Postfix) with ESMTPS id 5FD556140722
 for <tiff@lists.osgeo.org>; Thu, 10 Oct 2019 12:40:42 -0700 (PDT)
Received: from scrappy.simplesystems.org (scrappy.simplesystems.org
 [65.66.246.73])
 by smtp.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id x9AJeSbW002300;
 Thu, 10 Oct 2019 14:40:28 -0500 (CDT)
Date: Thu, 10 Oct 2019 14:40:28 -0500 (CDT)
From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
X-X-Sender: bfriesen@scrappy.simplesystems.org
To: Roger Leigh <rleigh@codelibre.net>
In-Reply-To: <edb305a5-4037-1cdb-06de-88ea9d92ea12@codelibre.net>
Message-ID: <alpine.GSO.2.20.1910101426570.24683@scrappy.simplesystems.org>
References: <010601d57882$4458a780$cd09f680$@perdrix.co.uk>
 <d721bb9d-1809-f18f-bbb5-af9a1867f047@codelibre.net>
 <a697eb91-af52-84e5-dbb3-afaa5ba318f7@sidefx.com>
 <000101d57923$441f0ec0$cc5d2c40$@perdrix.co.uk>
 <alpine.GSO.2.20.1910020818420.2070@freddy.simplesystems.org>
 <006401d57f55$75539fa0$5ffadee0$@perdrix.co.uk>
 <648e3c5a-d5cf-547c-6cbc-7bc5daa8c478@sidefx.com>
 <006a01d57f63$ace004f0$06a00ed0$@perdrix.co.uk>
 <edb305a5-4037-1cdb-06de-88ea9d92ea12@codelibre.net>
User-Agent: Alpine 2.20 (GSO 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed;
 BOUNDARY="3735943886-1691952160-1570736428=:24683"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
 (smtp.simplesystems.org [65.66.246.90]); Thu, 10 Oct 2019 14:40:28 -0500 (CDT)
Subject: Re: [Tiff] TIFF_IO_MAX too large for Windows XP
X-BeenThere: tiff@lists.osgeo.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.osgeo.org>
List-Unsubscribe: <https://lists.osgeo.org/mailman/options/tiff>,
 <mailto:tiff-request@lists.osgeo.org?subject=unsubscribe>
List-Post: <mailto:tiff@lists.osgeo.org>
List-Help: <mailto:tiff-request@lists.osgeo.org?subject=help>
List-Subscribe: <https://lists.osgeo.org/mailman/listinfo/tiff>,
 <mailto:tiff-request@lists.osgeo.org?subject=subscribe>
Cc: tiff@lists.osgeo.org
Errors-To: tiff-bounces@lists.osgeo.org
Sender: "Tiff" <tiff-bounces@lists.osgeo.org>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--3735943886-1691952160-1570736428=:24683
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 10 Oct 2019, Roger Leigh wrote:
>
> That said, I'm against including code of this nature, when we don't have 
> adequate testing or CI coverage.  It's a recipe for future regressions if the 
> XP codepaths are not tested.  It's difficult for a volunteer-driven project 
> to adequately support and maintain dead platforms.  There is a cost to adding 
> and maintaining this support, which needs to be borne in mind.  As is the 
> quality of the support if it's not being actively and routinely tested.  
> While I am willing to test, use and support libtiff on a wide range of 
> contemporary platforms, Windows XP is not such a platform.

There is no implied warranty. :-)

I think it is worth discussing if this rather high default limit 
should be reduced to something much smaller like 32k or 128k.

There is reason to believe that performance may improve (and not 
suffer) if I/Os use the underlying filesystem block size.  In the case 
of ZFS this might be 128k, and for NFS it might be some varying size, 
and who knows what for SMB/CIFS.  However, it may be that using the 
filesystem block size will only be an improvement if the write offset 
is also aligned to the filesystem block size and this might not be be 
easily feasible with TIFF (unless a short write is done to achieve a 
desired offset followed by full writes).

On a Unix (POSIX) type system, the filesystem block size can be 
determined using statvfs() or fstatvfs() and checking the f_bsize 
member.  More than likely there are similar interfaces for Windows to 
obtain the filesystem block size.

Absent consideration of underlying storage block sizes, there are 
optimimum read/write sizes when dealing with network I/O.

Bob
-- 
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt
--3735943886-1691952160-1570736428=:24683
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVGlmZiBtYWls
aW5nIGxpc3QKVGlmZkBsaXN0cy5vc2dlby5vcmcKaHR0cHM6Ly9saXN0cy5vc2dlby5vcmcvbWFp
bG1hbi9saXN0aW5mby90aWZmCg==

--3735943886-1691952160-1570736428=:24683--
