From owner-freebsd-hackers Tue Sep 17 13:10:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA11213 for hackers-outgoing; Tue, 17 Sep 1996 13:10:07 -0700 (PDT) Received: from celebration.net (indy.celebration.net [204.252.46.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA11208; Tue, 17 Sep 1996 13:10:02 -0700 (PDT) Received: (from dyson@localhost) by celebration.net (8.7.5/8.7.3) id PAA07313; Tue, 17 Sep 1996 15:04:28 -0500 (EST) From: "John S. Dyson" Message-Id: <199609172004.PAA07313@celebration.net> Subject: Re: attribute/inode caching To: terry@lambert.org (Terry Lambert) Date: Tue, 17 Sep 1996 15:04:28 -0500 (EST) Cc: dg@Root.COM, terry@lambert.org, bde@zeta.org.au, proff@suburbia.net, freebsd-hackers@freebsd.org, dyson@freebsd.org In-Reply-To: <199609171816.LAA04481@phaeton.artisoft.com> from "Terry Lambert" at Sep 17, 96 11:16:39 am X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (I am responding from my 'secret' site :-), because this stuff needs clarifying NOW.) > > Ask John Dyson. It has to do with the mapping of the file as a virtual > address space. Last time I looked in /a/src-fs/sys/ufs/ffs/ffs_vfsops.c, > I saw the following: > > > static int > ffs_oldfscompat(fs) > struct fs *fs; > { > ... > fs->fs_maxfilesize = (u_quad_t) 1LL << 39; > ... > > A clearly intentional limitation of 39 bit based on the mappable virtual > address space. > Actually, I think that the max file size is (2^9) * (2^31). The VM code structurally is not limited to that. (Modulo some bugs.) That limitation is due to the DEV_BSIZE addressibility. > > Yes, this is a VM limitation, but since that's how you do file I/O > (via faulting of pages mapped in a virtual address space), I can't > see how anything could be more relevent. > I believe that someone has already found/fixed my bugs in the calcuations causing overflows. The VM code is pretty much limited to 2^31 pages, or (2^31) * (2^12) == 2^43. The 2^40 is due to DEV_BSIZE. Doesn't look like the VM code is structurally the limiting factor. > > 1) There *IS* a limitation of 2^39 bits on individual file size. Yep, it says so in the ffs code, doesn't it? Looks bogus now. > 2) There *ISN'T* a limitation of 2^39 bits on device size (ask > Satoshi on that, if you don't believe me). Nor is there in the VM code. > 3) Files are mapped as VM objects (ie: have cache on their vnodes). Also their indirect blocks. > 4) Devices are not mapped as VM objects. The meta-data has a VMIO object on mounted VBLK filesystems. I haven't changed all of the specfs stuff yet. Right now, if you mount an FFS filesystem, your meta-data will reside in a VM object for the device. > > > I believe devices *should* be mapped as VM objects, and the quad arithmatic > overhead should be eaten (or the object references and manipulation should > be abstracted, duplicated for 64 and 32 bits, and flagged for reference > in the object itself). > The VM system is designed to be capable of supporting 2^31 pages. I changed it in a way so that we don't have to have nasty, inefficient u_quad_t's floating around everywhere. As I said, the infrastructure supports all VBLKS being VMIO directly, but I just haven't enabled it yet. The backing device for a ffs mounted filesystem is currently mapped as a VM object though. (That is where the benefit arises.) > > You need ihash because you can't page inodes into cache becuse they > aren't in the buffers hung off the device vnode, like you claim. > They are!!! (please refer to the code in -current, ignore 2.1.5). The backing VBLK device IS VVMIO (and has been for a few months)!!! > > I would like to see this happen, but it damn well has not, and the 39 > bit limitation (which is not a 42FS compatability hack, despite it's > location) is a limitation of *file* size and does not apply to *device* > size. > It is a file size limitation, and I think gratuitious. John