Re: nfs performance - idea.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2012/11/29 Myklebust, Trond <Trond.Myklebust@xxxxxxxxxx>:
>> -----Original Message-----
>> From: Łukasz Tasz [mailto:lukasz@xxxxxxx]
>> Sent: Thursday, November 29, 2012 9:00 AM
>> To: Myklebust, Trond
>> Cc: Adrien Kunysz; linux-nfs@xxxxxxxxxxxxxxx
>> Subject: Re: nfs performance - idea.
>>
>> 2012/11/29 Myklebust, Trond <Trond.Myklebust@xxxxxxxxxx>:
>> >> -----Original Message-----
>> >> From: Łukasz Tasz [mailto:lukasz@xxxxxxx]
>> >> Sent: Thursday, November 29, 2012 8:47 AM
>> >> To: Myklebust, Trond
>> >> Cc: Adrien Kunysz; linux-nfs@xxxxxxxxxxxxxxx
>> >> Subject: Re: nfs performance - idea.
>> >>
>> >> Hi, thanks a lot for answer,
>> >>
>> >> looks then even better! so to be 100% sure it good to traverse whole
>> >> path and open directory content.
>> >
>> > No. All you really need is the opendir(). If you want to make your own
>> > hack, all you need is a program that does something along the lines of
>> >
>> > DIR* p = opendir(".");
>> > if (p)
>> >      closedir(p);
>> >
>> I think I got what you mean, but in case of ./a/b/c/d/e just
>> opendir('./a/b/c/d/e') could end with "No such file or directory"
>>
>> that's why I'm thinking about:
>> for d in "./a/b/c/d/e".split('/')
>>    opendir(d)
>>
>>
>> >> One remark, since I did not mentioned it, I'm using NFSv3, is this
>> >> behavior same in NFSv3 and NFSv4?
>> >
>> > Yes. It is a consequence of the NFS close-to-open caching model, which is
>> common to all versions of NFS.
>> great,
>> could you please point me to document/manual which describe this model?
>>
>
> http://nfs.sourceforge.net/#faq_a8
again, many thanks!

>
>> thanks a lot for your help!
>> Łukasz
>>
>> >
>> >> thanks & regards
>> >> Lukasz Tasz
>> >> Łukasz Tasz
>> >>
>> >>
>> >> 2012/11/29 Myklebust, Trond <Trond.Myklebust@xxxxxxxxxx>:
>> >> >> -----Original Message-----
>> >> >> From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs-
>> >> >> owner@xxxxxxxxxxxxxxx] On Behalf Of Lukasz Tasz
>> >> >> Sent: Thursday, November 29, 2012 4:41 AM
>> >> >> To: Adrien Kunysz
>> >> >> Cc: linux-nfs@xxxxxxxxxxxxxxx
>> >> >> Subject: Re: nfs performance - idea.
>> >> >>
>> >> >> Any idea on this topic?
>> >> >>
>> >> >> Can I assume that "touch" could be interface for triggering
>> >> >> synchronising client state with server state?
>> >> >>
>> >> >
>> >> > 'ls' is better. All opendir() calls will trigger a revalidation of
>> >> > the directory
>> >> cache.
>> >> >
>> >> >
>> >> >> many thanks for help!
>> >> >> regards
>> >> >> Lukasz Tasz
>> >> >>
>> >> >>
>> >> >> 2012/11/14 Adrien Kunysz <adk@xxxxxxxxx>:
>> >> >> > On Wed, Nov 14, 2012 at 1:38 PM, Łukasz Tasz <lukasz@xxxxxxx>
>> wrote:
>> >> >> >> Hi all,
>> >> >> >>
>> >> >> >> I would like to consult some idea with you,
>> >> >> >>
>> >> >> >> Problem:
>> >> >> >> I have two processes which are doing some actions and one of
>> >> >> >> the action is done on a shared file system.
>> >> >> >> Issue is that this thing could be done only by one process, and
>> >> >> >> for this issue, locking mechanism is implemented.
>> >> >> >> Problem is that while one process is releasing lock, second one
>> >> >> >> is informed that file processing is finished, but unfortunately
>> >> >> >> files does not exists in context of second process.
>> >> >> >> Two processes are executed on two different hosts. NFS share is
>> >> >> >> mounted in a standard way, no special flag.
>> >> >> >> Problem I guess is with caches, lookupcache=none solves the
>> >> >> >> problem, but also causes others :) - performance.
>> >> >> >>
>> >> >> >> I know, it not possible to have all things at once - no complains.
>> >> >> >> But simple idea is that inside second process after
>> >> >> >> notification that files are generated execute touch function on
>> >> >> >> directory which holds files, This will cause unnecessary update
>> >> >> >> of modification date, but as a side effect I noticed  that also
>> >> >> >> file gets visible immediately on client hosts.
>> >> >> >>
>> >> >> >> That's why my question is if this is expected and reasonable
>> >> behaviour?
>> >> >> >> At the end I'm looking for kind of 'sync' command which will
>> >> >> >> cause synchronization of directories content inside client and
>> >> >> >> server something like flush() - but in NFS it's more complex.
>> >> >> >
>> >> >> > Doesn't fsync(2) do what you want? If not, can you explain why?
>> >> >> >
>> >> >> >> thanks in advance for help,
>> >> >> >>
>> >> >> >> regards
>> >> >> >> Lukasz
>> >> >> --
>> >> >> To unsubscribe from this list: send the line "unsubscribe linux-nfs"
>> >> >> in the body of a message to majordomo@xxxxxxxxxxxxxxx More
>> >> majordomo
>> >> >> info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux