> 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
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
> >>>>> " " == 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
> >&g
> 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
> >>>>> " " == 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
" " == 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 the server, and then invalidate the page cache
This would be i
> > " " == 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
" " == 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 sharing a file and
> > " " == 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
" " == 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 compromise?
I
> 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=fpatches/102394
fix this on the 4.1.4
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=0doc=fpatches/102394
fix this on the 4.1.4
12 matches
Mail list logo
