From owner-freebsd-bugs Thu May 10 1:30: 6 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 4988037B422 for ; Thu, 10 May 2001 01:30:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f4A8U2g49429; Thu, 10 May 2001 01:30:02 -0700 (PDT) (envelope-from gnats) Date: Thu, 10 May 2001 01:30:02 -0700 (PDT) Message-Id: <200105100830.f4A8U2g49429@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: Re: kern/27232: On NFSv3 mounted filesystems, stat returns st_blksize=512 Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/27232; it has been noted by GNATS. From: Bruce Evans To: Garrett Wollman Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/27232: On NFSv3 mounted filesystems, stat returns st_blksize=512 Date: Thu, 10 May 2001 18:24:04 +1000 (EST) On Wed, 9 May 2001, Garrett Wollman wrote: > < > > On NFSv3 mounts, stat returns st_blksize=512 for every regular file. > > This in turn is used by libc routines as a default buffer size, as it > > should be the 'optimal' io blocksize. > > No. It should be the block size used by the underlying filesystem's > block allocator, Correct. Even if there is no underlying filesystem's block allocator, stat() must fake it, and should fake it as well as possible. nfs seems to have regressed to always setting vap->va_blocksize to NFS_FABLKSIZE (512) in the v3 case (see nfs_subs.c). > and in which the file's `st_blocks' size-on-disk is > reportedi. No. At least under FreeBSD, st_blocks is in units of blocks with size S_BLKSIZE (512). It may count blocks for metadata, so it may be larger than the file size. > While SUS describes it as a ``preferred'' block size, and > the FreeBSD manual pages describe it as ``optimal ... for I/O'', the It is just the best available approximation to the optimal i/o size. If it is good enough for filesystem blocks, then it can't be very bad for userland i/o. > most important meaning of this field is as a multiplier of st_blocks > to determine the file's size. No. The multiplier is 512. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message