> My home directory lives on a SunOS 4.1.4 server, which helpfully expands
> 16-bit UIDs to 32 bits as signed quantities, not unsigned. So any uid above
> 32768 gets 0x added to it.
Doesn't
http://sunsolve.Sun.COM/pub-cgi/retrieve.pl?type=0&doc=fpatches/102394
fix this on the 4.1.4 s
> > " " == Jeff Epler <[EMAIL PROTECTED]> writes:
>
> > Is there a solution that would allow the kind of guarantee our
> > software wants with non-linux nfsds without the cache-blowing
> > that the change I'm suggesting causes?
>
> How about something like the following compro
> > " " == James Yarbrough <[EMAIL PROTECTED]> writes:
>
> > What is done for bypassing the cache when the size of a file
> > lock held by the reading/writing process is not a multiple of
> > the caching granularity? Consider two different clients with
> > processes shari
> >>>>> " " == Michael Eisler <[EMAIL PROTECTED]> writes:
>
> > Focus on correctness and do the expedient thing first, which
> > is:
> > - The first time a file is locked, flush dirty pages
> >to t
> Yes. fs/read_write calls the NFS subsystem. The problem then is that
> NFS uses the generic_file_{read,write,mmap}() interfaces. These are
> what enforce use of the page cache.
So, don't use generic*() when locking is active. It's what most other
UNIX-based NFS clients do. Even if it is "stupi
> >>>>> " " == Michael Eisler <[EMAIL PROTECTED]> writes:
>
> >> I'm not clear on why you want to enforce page alignedness
> >> though? As long as writes respect the lock boundaries (and not
> >> page boundari
> This problem that you are addressing is caused when solaris sends a
> zero length write (I assume to implement the "access" system call, but
> I haven't checked).
more likely a long standing bug in Solaris that hasn't been stomped.
Tony, you might let Sun know that you have a way to reproduce
7 matches
Mail list logo