Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Mar 1998 01:54:55 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        dima@tejblum.dnttm.rssi.ru (Dmitrij Tejblum)
Cc:        dmaddox@scsn.net, dyson@FreeBSD.ORG, current@FreeBSD.ORG
Subject:   Re: vnode_pager: *** WARNING *** stale FS code in system
Message-ID:  <199803070154.SAA27728@usr09.primenet.com>
In-Reply-To: <199803060930.MAA01918@tejblum.dnttm.rssi.ru> from "Dmitrij Tejblum" at Mar 6, 98 12:30:29 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > > Whomever has been doing the vnode_pager changes should likely
> > > fix the msdosfs also.  I am now working on fixing NFS, and am
> > > totally swamped.
> > 
> > If I recall correctly, the fix in question was submitted by Terry, and
> > committed by Michael Smith, so I expect one of them may want to take a
> > look at it...
> 
> Not quite so. The breakage was introduced by Terry in this commit. Now he 
> made a patch to fix the remaining filesystems, but the patch was not 
> committed.


The patches being discussed are at:

http://www.freebsd.org/~terry/D.GP.REST


> These changes completely break my "aesthetic principles", and 
> I started to argue. Then the weekend was finished, I lost the free 
> time.... So  --- sorry, I feel I lose due to timeout... On other hand, 
> there is a new weekend soon... :) Anyway, arguing with Terry is not a big 
> fun...

I'm willing to discuss (not argue) the design.

The reason I went the way I did was that putting the vnode_pager.c
code in the defaultops vector does nothing toward making the code
in vnode_pager.c _go away_, which is the eventual goal.  FS's which
can act as backing store need to have FS specific backing store
management, for a large variety of reasons (I can enumerate these
reasons again, if you need me to).

A secondary reason is that it means I have to make special code in
stacking FS's in order to be able to access the bypass (which I think
should be placed in the defaultops vector instead).  I think this is
bad because I think that FS stacking layers are going to vastly
outnumber local media FS's in the near future, providing we can get
the code to make them work committed for people to use as a foundation
for their own hacking.  I personally have three that I'd like to see
done, and other people have approached me about cryptography,
compression, NFS anonymous mount/WebNFS exposure via "//nfs/...",
the same thing for FTP, ACL's, and other stuff so wierd even I think
it's strange to want.

A tertiary reason is that if the code is in the defaultops vector,
I can't know when it becomes safe to remove from vnode_pager.c
and the defaultops vector.  There's no way to measure usage of
the defaultops code (that's kind of the point, really).

I don't think you've "lost by timeout", but by the same token, you've
failed to make a compelling case why putting it in the defaultops
is not ill-advised.

Like I said, I'm open to discussion on all of this; lately, I've
found a granularity where I've been on a roll, and nothing would
squelch that faster than a set of badly thought out patches.  It's
in my best interests to listen to what you have to say.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803070154.SAA27728>