> I haven't checked, but I assume that if a ledger is > garbage-collected and the writer tries to write to a bookie that > doesn't have it any longer, then the add request will fail. The request will not fail in this case. It'll behave the same as the first write on the ledger.
> My preference is to either leave as is or introduce a mechanism to > mark ledger metadata for deletion instead of actually deleting the > metadata. The one advantage of this last proposal is that the writer > will be able to cleanly close the ledger, independent of concurrent > delete requests. I don't see why the operation of a writer should be > affected by concurrent delete ledgers, although one obvious drawback > is that the writer will keep writing unnecessarily. I don't like the idea of marking for deletion, because it changes what deletion actually means. Under what circumstances would the metadata be needed at a later stage? If anyone actually uses the metadata, doesn't this mean that deletion isn't actually deletion. My preference for this would be that, if we find a ledger is open, we fence and then delete. This will notify the writer that something is wrong, and pass the error up to the application, which should be able to handle it.
