Date: Tue, 17 Sep 1996 15:04:28 -0500 (EST) From: "John S. Dyson" <dyson@celebration.net> To: terry@lambert.org (Terry Lambert) Cc: dg@Root.COM, terry@lambert.org, bde@zeta.org.au, proff@suburbia.net, freebsd-hackers@freebsd.org, dyson@freebsd.org Subject: Re: attribute/inode caching Message-ID: <199609172004.PAA07313@celebration.net> In-Reply-To: <199609171816.LAA04481@phaeton.artisoft.com> from "Terry Lambert" at Sep 17, 96 11:16:39 am
next in thread | previous in thread | raw e-mail | index | archive | help
(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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609172004.PAA07313>