From nobody Fri Jun 13 12:21:02 2025 X-Original-To: freebsd-java@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with UTF8SMTP id 4bJdmG17GKz5ptd9 for ; Fri, 13 Jun 2025 12:21:18 +0000 (UTC) (envelope-from haraldei@anduin.net) Received: from mail.anduin.net (mail.anduin.net [185.42.170.45]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with UTF8SMTPS id 4bJdmB6JXhz3C1Q for ; Fri, 13 Jun 2025 12:21:14 +0000 (UTC) (envelope-from haraldei@anduin.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=anduin.net header.s=dkim2021 header.b=2WRb558z; spf=pass (mx1.freebsd.org: domain of haraldei@anduin.net designates 185.42.170.45 as permitted sender) smtp.mailfrom=haraldei@anduin.net; dmarc=pass (policy=reject) header.from=anduin.net DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=anduin.net; s=dkim2021; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=5iQ1FzYDvUbeOhHOdAIMDaytP476+gPY2mMNsoVALrE=; t=1749817274; x=1750681274; b=2WRb558zw6Ybwmt6izMcDGHFYndBOUzEKr5LqSqNvTeuHK9bYjOGzTpEhTVKBjIFFoUbKJWOb03 A/TDIY43BcPmXt+J8TELATgALO7DKd1zTTrEFFJD6djdPYyOskSN4REsmztO78mOpBJ31adHfA7zC qOGQ+UREmarjC36Qwvzsgs5S6sidE5eTgyUqyaAnWvBcmTSRtzS+WJKh9kb+Jlwjrca6UN9yuEzQM ax9NNGGPl9FaQYil1AxwigKSCh3aKMX/QiaEdLUUkvqOdM0iGDc7zUp06BbwjFq4iVHH/zqrQ59Uf MyLG9UU0ctZroLuNfO6Q+uEMbbB9ELvoxmlg==; Received: by mail.anduin.net with utf8esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.97.1 (FreeBSD)) (envelope-from ) id 1uQ3P5-000000004XZ-03ha for freebsd-java@freebsd.org; Fri, 13 Jun 2025 12:21:04 +0000 Date: Fri, 13 Jun 2025 14:21:02 +0200 From: Harald Eilertsen To: FreeBSD Java mailing list Subject: Feedback requested: Support for -XX:AllocateHeapAt on ZFS? Message-ID: Mail-Followup-To: FreeBSD Java mailing list List-Id: Porting Java to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-java List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-java@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SA-Authenticated: Yes X-Spam-Score: -1.9 X-Spam-Level: - X-Spam-Report: host: mail.modirum.com | contact: hostmaster@modirum.com | scores: BAYES_00=-1.9,NO_RELAYS=-0.001 | autolearn=no autolearn_force=no, score=0 X-Spamd-Result: default: False [-0.25 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.991]; NEURAL_SPAM_LONG(0.78)[0.785]; NEURAL_HAM_MEDIUM(-0.55)[-0.548]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[anduin.net,reject]; R_SPF_ALLOW(-0.20)[+ip4:185.42.170.45/32]; R_DKIM_ALLOW(-0.20)[anduin.net:s=dkim2021]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[haraldei]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:62248, ipnet:185.42.170.0/24, country:EE]; MLMMJ_DEST(0.00)[freebsd-java@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[anduin.net:+] X-Rspamd-Queue-Id: 4bJdmB6JXhz3C1Q X-Spamd-Bar: / Hi, The code backing the `-XX:AllocateHeapAt=path` option to java calls the function posix_fallocate to reserve the space for the file in the file system. This will fail and return `EINVAL` if the underlying file system does not support the operation. On FreeBSD this is particularly relevant because the commonly used ZFS file system does not support this operation. For rationale see: https://freebsd-current.freebsd.narkive.com/5pbDPeIT/heads-up-posix-fallocate-support-removed-from-zfs-lld-affected https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068447.html OpenBSD is using the ftruncate function instead, which does not give the same guarantees as posix_fallocate. Likewise MacOSX will attempt to set the size via fcntl, but falls back to ftruncate if that does not work. To make things even more interesting, the glibc implementation of posix_fallocate used on most Linux based systems deviates from the posix standard by 'emulating' the feature if not supported by the underlying file system. https://www.man7.org/linux/man-pages/man3/posix_fallocate.3.html#CAVEATS My question is: Do we want to keep the strict posix compliance, which in practice means this feature is not supported on ZFS, or do we want to be less strict like the other platforms mentioned above? With the typical file system sizes of today, I don't think there should be any big dangers of using a less strict approach, but I'd like to hear others thought on the subject. Take care! Harald