Date: Thu, 1 Mar 2012 16:47:08 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Attilio Rao <attilio@freebsd.org> Cc: arch@freebsd.org, Gleb Kurtsou <gleb.kurtsou@gmail.com>, Pawel Jakub Dawidek <pjd@freebsd.org> Subject: Re: Prefaulting for i/o buffers Message-ID: <20120301144708.GV55074@deviant.kiev.zoral.com.ua> In-Reply-To: <CAJ-FndCSPHLGqkeTC6qiitap_zjgLki%2B8HWta-UxReVvntA9=g@mail.gmail.com> 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> <20120301141247.GE1336@garage.freebsd.pl> <CAJ-FndCSPHLGqkeTC6qiitap_zjgLki%2B8HWta-UxReVvntA9=g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--u2jkDaBVK38P9/ME Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 01, 2012 at 02:32:33PM +0000, Attilio Rao wrote: > 2012/3/1, Pawel Jakub Dawidek <pjd@freebsd.org>: > > 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 > >> > file > >> > 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. > >> > >> 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. >=20 > Can you please clarify on this as I really don't understand what you mean? >=20 > > > >> 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-weigh= t. >=20 > All I'm saying (and Gleb too) is that I don't see any benefit in > replicating all the vnodes lifecycle at the inode level and in the > filesystem specific implementation. > I don't see a semplification in the work to do, I don't think this is > going to be simpler for a single specific filesystem (without > mentioning the legacy support, which means re-implement inode handling > for every filesystem we have now), we just loose generality. >=20 > if you want a good example of a VFS primitive that was really > UFS-centric and it was mistakenly made generic is vn_start_write() and > sibillings. I guess it was introduced just to cater UFS snapshot > creation and then it poisoned other consumers. vn_start_write() has nothing to do with filesystem code at all. It is purely VFS layer operation, which shall not be called from fs code at all. vn_start_secondary_write() is sometimes useful for the filesystem itself. Suspension (not snapshotting) is very useful and allows to avoid some nasty issues with unmounts, remounts or guaranteed syncing of the filesystem. The fact that only UFS utilizes this functionality just shows that other filesystem implementors do not care about this correctness, or that other filesystems are not maintained. --u2jkDaBVK38P9/ME Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9Pi+sACgkQC3+MBN1Mb4j+DQCgzNdcihDFivaI+KoVGwEIcmRX LwMAnRAVHLgnFi+aeFHTTtPjRfwSLuQg =dNA5 -----END PGP SIGNATURE----- --u2jkDaBVK38P9/ME--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120301144708.GV55074>