From: Noveck, Dave (dave.noveck@netapp.com)
Date: 08/12/99-10:43:05 AM Z
Message-ID: <7F608EC0BDE6D111B53A00805FA7F7DA05D10BC9@tahoe.corp.netapp.com> From: "Noveck, Dave" <dave.noveck@netapp.com> Subject: RE: Caching issue (SHORT, really, I swear) Date: Thu, 12 Aug 1999 08:43:05 -0700 > I am afraid that the write back on close is not a panacea because on > Windows clients errors detected at this point cannot be > reported to the > user application. Quota/space errors are expected to be > reported in the > context of write calls. Ouch. > Perhaps someone familiar with Windows NFS > integration can comment on this in more detail. In DFS, which does > write back on close, we have found that various (dubious) tricks are > necessary to avoid this problem. To do a better job it be > nice to have > some kind of reservation system so that the client can be reasonably > sure that the server can accept all the dirty data it has. This leads > to a scheme like a) or c). Because of the Windows problem I > don't think > b) make a great fallback. I think that the many advantages of write > delegation make d) a bad choice. So your order of decreasing preference is c), a), b), d)? It seems also that the Windows issue strengthens the case for getting a better close-on-flush discrminator than file length alone. Mike Eisler used the word "critical". I was thinking that was an overstatement, but I'm coming around to the opinion that it isn't. Are you OK with the resolution I proposed of making the space_limit structure be just a file length for August but leaving it open for a better implementation later? This essentially a) with the chance to easily substitute a c) when it becomes available. I'm hoping that this will get people thinking in the space reservation direction early on as we start building with the option to change some of the details later
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:29 AM Z CST