Date: Tue, 17 Sep 1996 13:56:25 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dyson@celebration.net (John S. Dyson) Cc: terry@lambert.org, dg@Root.COM, bde@zeta.org.au, proff@suburbia.net, freebsd-hackers@freebsd.org, dyson@freebsd.org Subject: Re: attribute/inode caching Message-ID: <199609172056.NAA04771@phaeton.artisoft.com> In-Reply-To: <199609172004.PAA07313@celebration.net> from "John S. Dyson" at Sep 17, 96 03:04:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. Then there is no reason for vclean. The mapping association which it destroys is no longer applicable, since it is no longer the only reference instance. I have saved the original correspondence (or you can look it up in the -current list archives, which I suggest you do so that there is no question of me biasing the information) where we originally discussed the vclean interface. In it, you claimed that device/extent and vnode/extent mapping were irreconcilable because the device/extent mapping would cause a reduction in the mappable region down to 2^31, the max filesize (clearly, 31 pages == 4096/512 + 31 bits of blocks -- the origin of the 39). The purpose in maintaining it was because there was no way to recover a cache page that was not referenced by vnode because the divorce from the inode lost the base for the relative offset for the cache contents (ie: the vnode/inode data described a virtual address space). However, this current discussion has claimed that pages from a device will have a mapping off the device vnode. Unless somewhow some pages are more equal than others, this should include pages for which a vnode mapping exists. If this is true, then it is now possible to recover cached pages without an associated vnode by device/offset, and the vclean can be eliminated by LRU'ing the device vnode buffer list instead of the list of vnodes without an FS association. The pages are recoverable by making a device reference for any extent from the start of device, right? All that is required is that, now that you claim the device and the file vnode offset are in the same reference units, is to move the vnode offset from being a relative offset to an absolute (device relative instead of vnode relative). Thus vclean is doubley damned, since the operation it performs is to flush out essentially recoverable pages -- WHICH NEED NO LONGER BE FLUSHED, AND WERE ONLY BEING FLUSHED BECAUSE OF THEIR UNRECOVERABILITY. The sole remaining problem is for pseudo devices which span multiple physical devices (like CCD), since the cache must be split among the vnodes for the underlying devices. Unless you claim a CCD device established a mapping for the CCD device layer as well, and the a buffer of a file has three mappings: 1) The mapping to the vnode for the file reference, inherent in the cache unification (vnode/extent caching). 2) The mapping for the device vnode, inherent in your explanation of inode caching (device/extent caching). 3) The additional submapping for the device vnode for the real device as a component of a CCD composite device. Am I mistaken here? What am I missing? I really disliked the move of the fs_maxfilesize into the in core superblock in the first place -- does this mean it can go away entirely, and we can recover Sun FFS layout interoperability? I would be all for that... Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609172056.NAA04771>