The touching doesn't have to be that timely.
If the indexed is configured to only keep old segments less than x
hours old, you just check if any of the timestamps are with x hours,
and if not you can delete the segments. So even if the reader is late
updating the timestamp - they would need to be VERY late.
You also need synchronization between the segment deleters, since you
wouldn't want everyone doing it.
On Jan 18, 2007, at 4:39 PM, Marvin Humphrey wrote:
On Jan 18, 2007, at 2:17 PM, Michael McCandless wrote:
How about if each reader were assigned a unique ID (eg hostname) by
the application, and wrote a file ($ID.inuse or something) into the
index dir referencing the segments_N that it's currently using?
It would have to go in the old /tmp lock dir to deal with the
permissions issue.
I really prefer to have locking managed via the index dir rather
than a shared dir within /tmp.
Without that, multiple machines attempting to write to an index on
a shared volume don't know about each other unless you specifically
manage the locking mechanism -- and thus may corrupt an index.
Plus, it's simpler and better for all the reasons outlined a couple
weeks ago.
This wouldn't require
locking (which scares me on NFS)
Well, the thing about the scheme using file locking is that it
tests the locking mechanism once per Directory per session before
executing any delete ops. There's a cost for doing this, but I
don't think it's significant in the grand scheme.
The touching mechanism scares me. :) It's hard to guarantee that it
will always occur in a timely manner.
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
