Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 16 Oct 2002 10:01:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 16 Oct 2002 10:01:09 -0400 Received: from zero.aec.at ([193.170.194.10]:51206 "EHLO zero.aec.at") by vger.kernel.org with ESMTP id ; Wed, 16 Oct 2002 10:01:08 -0400 Date: Wed, 16 Oct 2002 16:06:58 +0200 From: Andi Kleen To: linux-kernel@vger.kernel.org, peter@chubb.wattle.id.au Subject: statfs64 missing Message-ID: <20021016140658.GA8461@averell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 982 Lines: 24 I notice 2.5 has 64bit sector_t but no statfs64() system call for 32bit architectures. How is df supposed to report it? statfs uses 32bit block counts. The currently limit depends on the block size, the bigger your block size the more bytes it can report. This problem already exists on 2.4. You can actually access NFS servers which have more than 2TB of disk space. NFS uses the local write size as block size. When you are lucky then 0xfffffffff*wsize is bigger than what your NFS server reports. If not you get wrong results. The only workaround currently is to increase wsize, but that has its limits too. Fixing it properly probably requires statfs64(). Any reason why this was not included in the sector_t patchkit ? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/