On Thu, Apr 22, 2010 at 11:19:57AM +0100, Simon Wilkinson wrote:
> Okay, I understand now. And you're right, this is somewhat strange
> behaviour, which has been there for years. And it won't help in the
> cooperative locking case, sadly.
>
> When a file is opened RW, and is marked as being di
On 22 Apr 2010, at 08:42, Hans-Werner Paulsen wrote:
I do not know the exact semantics of the AFS filesystem, and
therefore I
do not know that it is a bug. Is it really a bug?
Running the following program on machine A
fd = open("xxx",O_RDONLY);
while (1) {
ret = fstat(fd,&buf);
print
On Wed, Apr 21, 2010 at 09:48:27AM -0400, Derrick Brashear wrote:
> if you opened it O_RDWR on this client, it better have a valid callback.
>
> if it's modified and you still have it open, the callback is broken.
> if the client doesn't refetch, it's a bug, and it has nothing to do
> with locking
If the CM omits to flush in this case, that's a plausible result. Viced will
BCB when the lock is released, but if the changed data hasn't been written
back, the cooperating clients lose.
Matt
- "Simon Wilkinson" wrote:
>
> I strongly suspect that the copy on the client is up to date, at
On 21 Apr 2010, at 14:26, Hans-Werner Paulsen wrote:
On Wed, Apr 21, 2010 at 08:46:54AM -0400, Derrick Brashear wrote:
if you have a valid callback, the file better be up to date. uh
Hm, I do not understand. I have the following code on one client:
(1) fd = open("afs-file",O_RDWR)
(2) flo
On Wed, Apr 21, 2010 at 9:26 AM, Hans-Werner Paulsen
wrote:
> On Wed, Apr 21, 2010 at 08:46:54AM -0400, Derrick Brashear wrote:
>> if you have a valid callback, the file better be up to date. uh
> Hm, I do not understand. I have the following code on one client:
> (1) fd = open("afs-file",O_RD
On Wed, Apr 21, 2010 at 08:46:54AM -0400, Derrick Brashear wrote:
> if you have a valid callback, the file better be up to date. uh
Hm, I do not understand. I have the following code on one client:
(1) fd = open("afs-file",O_RDWR)
(2) flock(fd,LOCK_EX)
...
When the file is modified on the files
On Wed, Apr 21, 2010 at 8:11 AM, Hans-Werner Paulsen
wrote:
> On Wed, Apr 21, 2010 at 12:49:39PM +0100, Simon Wilkinson wrote:
>> >When there are two processes (on different machines) executing that
>> >code, the (2) flock call has to update the local copy of the afs-file,
>> >otherwise locking is
On Wed, Apr 21, 2010 at 12:49:39PM +0100, Simon Wilkinson wrote:
> >When there are two processes (on different machines) executing that
> >code, the (2) flock call has to update the local copy of the afs-file,
> >otherwise locking is useless. And the (3) flock call has to sync the
> >local copy wit
When there are two processes (on different machines) executing that
code, the (2) flock call has to update the local copy of the afs-file,
otherwise locking is useless. And the (3) flock call has to sync the
local copy with the fileserver.
Writing a small test program I see that this synchronizati
On Mon, Apr 12, 2010 at 12:34:23AM -0400, Derrick Brashear wrote:
> On Sun, Apr 11, 2010 at 11:13 PM, Adam Megacz wrote:
> >
> > Brandon Simmons writes:
> >> Thanks for the response. It seems like whole-file locking in sqlite
> >> would be a good choice for me in any case,
> >
> >> In a situation
On Sun, Apr 11, 2010 at 11:13 PM, Adam Megacz wrote:
>
> Brandon Simmons writes:
>> Thanks for the response. It seems like whole-file locking in sqlite
>> would be a good choice for me in any case,
>
>> In a situation where the whole-file locking scheme is used, would AFS
>> be an acceptable choi
Brandon Simmons writes:
> Thanks for the response. It seems like whole-file locking in sqlite
> would be a good choice for me in any case,
> In a situation where the whole-file locking scheme is used, would AFS
> be an acceptable choice? Would it be better than NFS?
I had the same idea, and tri
13 matches
Mail list logo
