Re: Prefaulting for i/o buffers

2012/3/1, Pawel Jakub Dawidek <pjd@xxxxxxxxxxx>:
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.

Can you please clarify on this as I really don't understand what you mean?


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.

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.

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.

Thanks,
Attilio


--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Prefaulting for i/o buffers
    ... tends to overcomplicate VFS. ... About ZFS rangelocks absorbing the VFS ones, I think this is a minor ... generalizing a new mechanism, it is using a general mechanism in a ... this is general purpose mechanism used by more than one file system. ...
    (freebsd-arch)
  • Re: Prefaulting for i/o buffers
    ... tends to overcomplicate VFS. ... About ZFS rangelocks absorbing the VFS ones, I think this is a minor ... generalizing a new mechanism, it is using a general mechanism in a ... this is general purpose mechanism used by more than one file system. ...
    (freebsd-arch)
  • Re: Prefaulting for i/o buffers
    ... tends to overcomplicate VFS. ... About ZFS rangelocks absorbing the VFS ones, I think this is a minor ... generalizing a new mechanism, it is using a general mechanism in a ... this is general purpose mechanism used by more than one file system. ...
    (freebsd-arch)
  • Re: Prefaulting for i/o buffers
    ... I did not implement rangelocking for ZFS. ... this is general purpose mechanism used by more than one file system. ... Our VFS is very UFS-centric. ... Noone implemented rangelocking in VFS, so no file system can use it. ...
    (freebsd-arch)
  • Re: Prefaulting for i/o buffers
    ... once that is used by one file system, ... which all are separate mount points from VFS perspective. ... The same block would be cached 111 times by the buffer cache. ... filesystem specific implementation. ...
    (freebsd-arch)