because the session close clears connection->priv. We need to check at
each site anyway, either for null session, or for session->closed. So
check for null session.
Conflicts:
src/mon/Monitor.cc
src/mon/OSDMonitor.cc
src/mon/PGMonitor.cc
This is cheating a bit, but should be harmless. Basically, we spit off the
snaprealm when we unlink to keep the hierarchy vs snaprealm invariants
intact. But we don't really care if the client does so, so we skip the
client_snap notifications.
That means the client will leave unlinked inodes in the realm they were
in at the time of unlink. I'm pretty sure that won't cause problems
later.
Otherwise we get this on the peer:
msg/SimpleMessenger.cc: In function 'int SimpleMessenger::Pipe::accept()':
msg/SimpleMessenger.cc:767: FAILED assert(existing->state == STATE_CONNECTING)
1: (SimpleMessenger::Pipe::accept()+0x14b2) [0x654888]
2: (SimpleMessenger::Pipe::reader()+0x32) [0x65538c]
3: (SimpleMessenger::Pipe::Reader::entry()+0x19) [0x649493]
4: (Thread::_entry_func(void*)+0x20) [0x659b06]
5: /lib/libpthread.so.0 [0x7fcdc782f73a]
6: (clone()+0x6d) [0x7fcdc6a5969d]
NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this.
At least until btrfs snap deletion doesn't require a full commit (i.e. each
commit cycle doesn't do a commit for the snap creation AND another for the
old snap deletion).
We used to do this to avoid corrupting the filestore, but since we can now
either roll forward with the writeahead journal OR roll back using btrfs
snaps, this is useless. It wasn't a full solution anyway.
...even if the inode itself doesn't need to be cowed. In particular, we
do the pre_cow_old_inode() thing, so it frequently doesn't need to be cowed,
but the dentry does when we are say unlinking a directory or some such.
Without this patch, on CentOS 5.4 ./configure reports that
sync_file_range is missing, but HAVE_SYNC_FILE_RANGE ends
up being defined in src/acconfig.h anyway.
Compile tested on CentOS 5.4 (which does not have sync_file_range(2)
in distro glibc) and Fedora 11 (which does).
Signed-off-by: Jim Schutt <jaschut@sandia.gov>
This ensures that we don't pipeline dentry linkage updates when there
are witnesses. That can cause problems because replicas don't see
projected dentry linkage info, and will get confused when they look at
the replica of the srcdn and it's, say, NULL and not srci.
