Date: Thu, 1 Mar 2012 15:12:47 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Gleb Kurtsou <gleb.kurtsou@gmail.com> Cc: Attilio Rao <attilio@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com>, arch@freebsd.org Subject: Re: Prefaulting for i/o buffers Message-ID: <20120301141247.GE1336@garage.freebsd.pl> In-Reply-To: <20120301111624.GB30991@reks> References: <20120203193719.GB3283@deviant.kiev.zoral.com.ua> <CAJ-FndABi21GfcCRTZizCPc_Mnxm1EY271BiXcYt9SD_zXFpXw@mail.gmail.com> <20120225151334.GH1344@garage.freebsd.pl> <CAJ-FndBBKHrpB1MNJTXx8gkFXR2d-O6k5-HJeOAyv2DznpN-QQ@mail.gmail.com> <20120225194630.GI1344@garage.freebsd.pl> <20120301111624.GB30991@reks>
next in thread | previous in thread | raw e-mail | index | archive | help
--qp4W5+cUSnZs0RIF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 01, 2012 at 01:16:24PM +0200, Gleb Kurtsou wrote: > On (25/02/2012 20:46), Pawel Jakub Dawidek wrote: > > - "Every file system needs cache. Let's make it general, so that all fi= le > > systems can use it!" Well, for VFS each file system is a separate > > entity, which is not the case for ZFS. ZFS can cache one block only > > once that is used by one file system, 10 clones and 100 snapshots, > > which all are separate mount points from VFS perspective. > > The same block would be cached 111 times by the buffer cache. >=20 > Hmm. But this one is optional. Use vop_cachedlookup (or call > cache_entry() on your own), add a number of cache_prune calls. It's > pretty much library-like design you describe below. Yes, namecache is already library-like, but I was talking about the buffer cache. I managed to bypass it eventually with suggestions from ups@, but for a long time I was sure it isn't at all possible. > Everybody agrees that VFS needs more care. But there haven't been much > of concrete suggestions or at least there is no VFS TODO list. Everybody agrees on that, true, but we disagree on the direction we should move our VFS, ie. make it more light-weight vs. more heavy-weight. > > When looking at the big picture, it would be nice to have all this > > general stuff like rangelocking, quota, buffer cache, etc. as some kind > > of libraries for file systems to use and not something that is > > mandatory. If I develop a file system for FreeBSD only and I don't want > > to reinvent the wheel, I can use those libraries. If I port file system > > to FreeBSD or develop a file system that doesn't really need those > > libraries I'm not forced to use them. >=20 > Are you aware of a real "libraries for file systems" VFS example? It > sounds very interesting but I'm afraid it's going to look good only in > theory. E.g. locking at file system level (Darwin, Dragonfly BSD) looks > rather messy (IMHO) and more likely to be bug prone. On the other side > Linux has optional per file system rename lock making VOP_RENAME > implementation much easier, while ours is tremendously difficult to do > right. There are not many examples for such libraries, but the namecache is one of them. Things like rangelocking definiately look like a good candidate to make it a library. > > All this might make a good working group subject at BSDCan devsummit. > > We could cross swords there:) >=20 > Unfortunately I'm afraid I won't make there too. And most likely will > miss EuroBSD/MeetBSD 2012 in Warsaw as well. I have a number of fresh > ideas about namecache I'd love to discuss. What do you think about > organising preliminary group meeting on fs@ or arch@? :) Sounds good. Both forums seems suitable, just pick one. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --qp4W5+cUSnZs0RIF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9Pg98ACgkQForvXbEpPzSpdACfdxehVqvpgF/3wXtT3OJCIw0Z GOMAoKlqRr5LjBU7koitFf+7VGbMC6z+ =4IE/ -----END PGP SIGNATURE----- --qp4W5+cUSnZs0RIF--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120301141247.GE1336>