On Wed, Aug 13, 2014 at 12:32 PM, Philip Martin <philip.mar...@wandisco.com> wrote:
> Stefan Fuhrmann <stefan.fuhrm...@wandisco.com> writes: > > > The solution seems to be to simply destroy the txn_dir_cache > > instance at the begin of the commit. That comes at some extra > > cost but that is still proportional to the size of the commit. > > There would be no cost to mod_dav_svn since the txn_dir_cache is already > NULL when handling MERGE. There would be a cost to svn:// and file://. > > > The only sequence that would get us into real trouble is > > > > thread / process A: modify txn > > thread / process B: modify txn > > thread / process A: modify txn (via same fs_t as before) > > > > Since A won't re-read the directory contents and may therefore > > return "path not found" errors or miss earlier modifications to a > > given node / sub-tree and use a new copy for the following mods. > > But I guess we don't support that sequence at all. > > We don't support it right now because it doesn't work, but do we want it > to work? fs-test 44 is the new test I wrote: it FAILS for FSFS but is a > PASS for BDB and FSX. It is also a PASS for 1.6 FSFS. > Hm. Right now, we haven't changed the on-disk representation of in-txn directories. It is still append-only. So, we could cache the directory file size along with the contents and use that for an OOD check. I wouldn't want to do it for 1.9 but it is certainly an option later. The driver behind this would be concurrent puts. -- Stefan^2.
