From owner-freebsd-fs@FreeBSD.ORG  Sun Jul  4 02:09:16 2004
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 4EB4316A4CE; Sun,  4 Jul 2004 02:09:16 +0000 (GMT)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 34E3143D31; Sun,  4 Jul 2004 02:09:16 +0000 (GMT)
	(envelope-from bright@elvis.mu.org)
Received: by elvis.mu.org (Postfix, from userid 1192)
	id EDDDC5C843; Sat,  3 Jul 2004 19:09:15 -0700 (PDT)
Date: Sat, 3 Jul 2004 19:09:15 -0700
From: Alfred Perlstein <alfred@freebsd.org>
To: Tim Robbins <tjr@freebsd.org>
Message-ID: <20040704020915.GI95729@elvis.mu.org>
References: <200407031322.i63DMdqC084182@repoman.freebsd.org>
	<20040703230127.GG95729@elvis.mu.org>
	<20040704004444.GA52008@cat.robbins.dropbear.id.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040704004444.GA52008@cat.robbins.dropbear.id.au>
User-Agent: Mutt/1.4.2.1i
cc: freebsd-fs@freebsd.org
Subject: Re: cvs commit: src/sys/conf NOTES files options src/sys/fs/msdosfs
	msdosfs_fileno.c msdosfs_vfsops.c msdosfs_vnops.c msdosfsmount.h
	src/sys/modules/msdosfs Makefile
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Jul 2004 02:09:16 -0000

* Tim Robbins <tjr@freebsd.org> [040703 17:41] wrote:
> On Sat, Jul 03, 2004 at 04:01:27PM -0700, Alfred Perlstein wrote:
> > What are the implications of expanding the VFS API to take 64bit
> > inodes?
> 
> Widening ino_t to 64 bits would change the layout/size of struct stat, so
> we'd have to add a new stat() syscall (as well as fstat(), lstat()) and add
> compatibility code for binaries that expect the old layout. We'd also have
> to sweep through VFS to find the instances where i-numbers are being stored
> in wrong types, e.g. struct vattr's va_fileid member uses 'long' instead
> of 'ino_t' for some reason. I think it's something that would be best
> left until 6-CURRENT.

Bah, we can do it. :)

-- 
- Alfred Perlstein
- Research Engineering Development Inc.
- email: bright@mu.org cell: 408-480-4684