FSSlaveDirectoryProvider uses two directories on local disk: "1" and "2"
On shared location there is also two directories "1" and "2". In a case of a shared file system
this has been done to make sure there is a consistent copy of the index at all times

But in a case of FSSlaveDirectoryProvider even if it is accessing dirs "1" and "2" on shared storage, why is it needed on local disk? Say at point t1 local dir contains files: segments.gen, 1.cfs and 2.cfs
at point t2 content of a current index on shared drive is new, say segments.gen, 2.cfs and 3.cfs. Now, our (only) locar dir is directly synchronized with remote dir. At this point 1.cfs would be deleted, but it does not pose a problem even if there is a reader open - it will be really deleted when last reader using it is closed ?

Would it save a lot of disk space if FSSlaveDirectoryProvider didn't use two dirs for local index on slave machine?

because local disk is much faster to perform searches, and many network filesystems have broken locking or delete-after-last close (or both). Of course it might work, but I wouldn't recommend it unless you're prepared to do some extensive testing.


Yes thinking about it, you might be right the copy method could be rewritten to need a single directory, but it would need to copy first all new segments, and then as last step copy the segments.gen and then flag the obsolete segments to be deleted; I guess that to perform this operation you might still need enough disk space to potentially hold twice the index size. It might be interesting to explore this, also you might avoid some network copies but I'm not sure how important that would be, it's not that much to be worried about usually.

Feel free to investigate and propose a patch to the mailing list, but consider that we're currently polishing an Infinispan based Directory which has many advantages, so that's the priority currently (you might want to try that).