On Monday 17 Dec 2012 14:35:45 you wrote:
> This code was written before I joined up, so at this point I can only make
> guesses about why it was implemented this way. I think I'm the only NFS
> developer using Arch, so you might get better information asking on
> linux-...@vger.kernel.org.
Thank
On 12/17/2012 06:12 AM, Paul Gideon Dann wrote:
> On Friday 14 Dec 2012 11:09:59 you wrote:
>> I'm sorry, but I think you are misunderstanding the mount option. "nocto"
>> is used to cut down on getattrs when deciding if a file has changed, and
>> has nothing to do with when writes are sent to the
On Friday 14 Dec 2012 11:09:59 you wrote:
> I'm sorry, but I think you are misunderstanding the mount option. "nocto"
> is used to cut down on getattrs when deciding if a file has changed, and
> has nothing to do with when writes are sent to the server.
That seems to be the case for the Linux NFS
On 12/14/2012 04:50 AM, Paul Gideon Dann wrote:
> On Thursday 13 Dec 2012 15:53:32 Bryan wrote:
>> I double checked with Trond and he agrees that we shouldn't defer the flush
>> because that would cause us to hold the file open for longer than we really
>> should (and it would make NFS sillyrenames
On Thursday 13 Dec 2012 15:53:32 Bryan wrote:
> I double checked with Trond and he agrees that we shouldn't defer the flush
> because that would cause us to hold the file open for longer than we really
> should (and it would make NFS sillyrenames more difficult, too).
I thought that's why the "noc
On Wed, Dec 12, 2012 at 9:34 AM, Paul Gideon Dann wrote:
> On Wednesday 12 Dec 2012 08:58:52 you wrote:
> > On 12/12/2012 05:35 AM, Paul Gideon Dann wrote:
> > > On Tuesday 11 Dec 2012 12:08:46 you wrote:
> > >> After more poking-about: filp_close() in the VFS calls
> nfs_file_flush(),
> > >> whic
On 12/12/2012 05:35 AM, Paul Gideon Dann wrote:
> On Tuesday 11 Dec 2012 12:08:46 you wrote:
>> After more poking-about: filp_close() in the VFS calls nfs_file_flush(),
>> which writes the file back to the server. The struct file we're given is
>> freed up shortly after calling flush, so this look
On 12/11/2012 10:19 AM, Bryan Schumaker wrote:
> On 12/11/2012 09:55 AM, Paul Gideon Dann wrote:
>> On Tuesday 11 Dec 2012 09:07:12 Bryan Schumaker wrote:
>>> After thinking on this some more and going through the code again, I think
>>> that the "nocto" only affects writing and fetching attributes
On 12/11/2012 09:55 AM, Paul Gideon Dann wrote:
> On Tuesday 11 Dec 2012 09:07:12 Bryan Schumaker wrote:
>> After thinking on this some more and going through the code again, I think
>> that the "nocto" only affects writing and fetching attributes for a file
>> (the man page mentions using a heuris
On Tuesday 11 Dec 2012 09:07:12 Bryan Schumaker wrote:
> After thinking on this some more and going through the code again, I think
> that the "nocto" only affects writing and fetching attributes for a file
> (the man page mentions using a heuristic to determine if files have changed
> on the serve
On 12/10/2012 10:23 AM, Paul Gideon Dann wrote:
> On Monday 10 Dec 2012 09:26:51 Bryan Schumaker wrote:
>> On 12/10/2012 08:11 AM, Paul Gideon Dann wrote:
>>> Does anyone have any idea why "nocto" doesn't have the effect I was hoping
>>> it would? The "async" option works as expected, but it's mor
On Monday 10 Dec 2012 09:26:51 Bryan Schumaker wrote:
> On 12/10/2012 08:11 AM, Paul Gideon Dann wrote:
> > Does anyone have any idea why "nocto" doesn't have the effect I was hoping
> > it would? The "async" option works as expected, but it's more important
> > to me that the client cache is corr
On 12/10/2012 08:11 AM, Paul Gideon Dann wrote:
> I've been learning about the close-to-open policy of NFS, which causes each
> file to be flushed to the server as it's closed, to ensure consistency across
> clients. This is a big performance hit when trying to upgrade the system,
> because of
I've been learning about the close-to-open policy of NFS, which causes each
file to be flushed to the server as it's closed, to ensure consistency across
clients. This is a big performance hit when trying to upgrade the system,
because of the numerous writes to small files.
I know about the "a
14 matches
Mail list logo
