Date: Mon, 30 Oct 1995 23:21:53 -0800 (PST) From: Julian Elischer <julian@ref.tfs.com> To: terry@lambert.org (Terry Lambert) Cc: current@freebsd.org Subject: Re: *MORE* FS problems, please fix! Message-ID: <199510310721.XAA14908@ref.tfs.com> In-Reply-To: <199510302039.NAA06584@phaeton.artisoft.com> from "Terry Lambert" at Oct 30, 95 01:39:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Well, if I can't get patches committed, the least I can do is > complain about problems and hope someone else can get their possibly > identical patches committed instead. Actually terry, I am packratting your patches as are john and david.. I fully intend on getting either THEM or a variant into the tree. there are a couple of things in the way:A Bruce, and a couple of other people have asked that we not stir up that pot at the moment as there are various changes 'out' but pending, and changes applied now just make things harder. john has said to me and others that he wants to take your patches and integrate them into a larger set of patches he's scheming on.. As he's the prime heavy in that area I cede to him and his requests but please don't for one minute think we are ignoring you or your patches. I personally are tired of the "please hold off, I got patches outstanding appeal" and When I go back to OZ in 6 weeks I'm going to be active in the tree the likes of I can only dream of at the moment with this albatros of a project hanging around my neck at work.. don't give up on us yet.. we all hold you in enough esteem to not dismiss anything you say, (though you seem to be in so many OS's that sometimes you get confused about which does what..) :) > > > The spotlight this time is on file locking. > > The locking subsystem is *incorrectly* implementing locking via a > call to vn_* from the file system specific lock code. > > > The design says that the FS specific lock code is, in fact, advisory. > > This means that the locking should be implemented at a higher layer > (in the system call implementations), and then the FS specific lock > code called if the lock is granted at the higher layer. > > Basically, this means the for most file systems, the lock calls should > be simple success returns. > > The exception is NFS, which must assert a lock remotely. > > For file systems where the FS spcific locking code is non-null, a > failure return for the FS specific locking code means back off the > already granted lock at the higher level. > > This has the decided advantage of causing the FS to not "go remote" > if a local conflict exists: a local conflict will result in a remote > conflict anyway. > > It also means that FS layering is possible without afailure in the > lock case. Currently, a lock asserted at one layer would cause a > failure on the assertion at a lower layer (worst case) or a duplicate > assertion (best case). > > For remote file systems (DOS/NetWare/LanMan) where overlapping lock > regions are not coelesced, either one is fatal. > > > Whoever reimplements this change (my patches aren't "good enough") > should note that it will be about as large in scope as the patches > I already submitted for FS layering. This means that you probably > don't stand a chance of success unless you have commit priveledges. I don't thisnk that your patches aren't good enough terry.. the trouble is that we all try to not commit code that has not had a second set of eyes pass over it, and you tend to be submitting code that can't be looked at 'quickly'. You are hacking around in the most sensitive area of the system and 1/ it takes time to check your changes .. ( 2/ there aren't that many people who feel comfortable in claiming that they know enough about it to judge it.. basically the 2.1 release saga has got us pretty much on hold due to personnel shortage.. > > I DO understand how you feel about it and do think that what we really need is a way that we can ensure that these type sof things can be passed by the right people for comment and actually get the comments required.. > 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?199510310721.XAA14908>