From owner-cvs-sys Sat Oct 12 15:44:25 1996 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA06752 for cvs-sys-outgoing; Sat, 12 Oct 1996 15:44:25 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA06733; Sat, 12 Oct 1996 15:44:13 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id IAA09080; Sun, 13 Oct 1996 08:38:07 +1000 Date: Sun, 13 Oct 1996 08:38:07 +1000 From: Bruce Evans Message-Id: <199610122238.IAA09080@godzilla.zeta.org.au> To: bde@freefall.freebsd.org, dg@root.com Subject: Re: cvs commit: src/sys/ufs/ffs fs.h Cc: cvs-all@freefall.freebsd.org, CVS-committers@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Sender: owner-cvs-sys@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Modified: sys/ufs/ffs fs.h >> Log: >> Fixed lblktosize(). It overflowed at 2G. This bug only affected >> ufs_read() and ufs_write(). > > Are you going to bring this into -stable, or do you think it is unnecessary >since we don't support >2GB files there anyway due to VM page restrictions? I didn't plan to. Perhaps we should set fs_maxfilesize to 2G-1. This should be safer than doing nothing or attempting to trap all the overflows. I thought that large files worked in -current. A long time ago, I put a 1 TB file system on /dev/vn0. The metadata must have gone beyond 2G logical in the underlying file. Bruce