Special wait mask is passed through lock wait mask to parent object.
Caller adds item to a list on the subtree root.
Removal of wait item automatically removes from said list.
Subtree topology changes adjust authchange wait lists.
Migrator auth change update waits waiters. Import/export should be
protected by freeze/thaw or the blanket wakeups.
The print function is only called when we're about to crash anyway,
and the datamember 'foo' is allocated by ptmalloc, not tcmalloc. Freeing
it via tcmalloc causes its own crash which pollutes our debugging and
incorrectly sticks tcmalloc into the stack. So, just don't free.
The forcefed mapping relies on a parent map. However, the current
implementation assumes that the parent mapping is unique for all rules. If
that is not the case (i.e., some osd exists in multiple hierarchies) then
we cannot assert that the TAKE matches the calculated force_context.
For now, we can just fail the mapping in that case (we don't use forcefed
mappings yet). The real solution is probably to define parent maps for
all possible hierarchies (i.e., starting at each unique TAKE starting
point).
Signed-off-by: Sage Weil <sage@newdream.net>
We can't trust the inode rstat size without holding the locks. We can
look at our auth frags and though without fear of a false positive
ENOTEMPTY, however.
Rename the function, introduce a helper for the locked check, update
comments, etc.
Strictly speaking, this changes the encoding. But, the encoding was
broken before, because ceph_timespec in ns but we were actually encoding
us.
But it's all subsecond resolution, so who cares. Just change it!
This fixes a race when reading and deleting objects, as evidenced by
cp bigfile a
mkdir .snap/foo
rmdir a
diff bigfile .snap/foo/a <-- reads cloned object before it hits disk
Reproduced by snaptest-snap-rm-cmp.sh.
Signed-off-by: Sage Weil <sage@newdream.net>
We only want to do a null snapflush if we _know_ there isn't another one
coming: that is, there aren't any outstanding issued excl/wr cap bits at
the client. The old test has the bitwise NOT backwards. We can also
limit the test to the bits we care about.
This (usually) reproduced a bug where:
- we write a big file
- snap it
- remove it. this makes the mds cow it.
- cp the snapped version.
- mds syncs the head
- client starts writeback
- (sometimes!) client sends other caps back to the mds
- mds does null flushsnap, not realizing a real one is still coming
The problem is that we may be rdlocking items with a different auth than
the main item we are modifying, so forwarding based on lock state is
inconsistent with our requirement that we be on the modified item's auth.
Either we can somehow mark whether the locked item is the "main thing" we
are operating on, or we can drop the forward behavior from the locker and
put any forwarding heuristics elsewhere. I'm opting for the latter.
Don't use pick_inode_snap is totally wrong (it depends on the current set
of snaps, etc.).. look up the inode directly via the ino and last snapid,
which we have. Fixes a failure at the assert.
Reported-by: Thomas Mueller <thomas@chaschperli.ch>
Signed-off-by: Sage Weil <sage@newdream.net>
We won't get a flushsnap when the client has EXCL/WR caps but no dirty
data. The MDS needs to release the snapped inode's locks when it gets a
normal update but no FLUSHSNAP.
This lets us issue the most leases/caps possible. It also ensure we can
issue caps in the snapped namespace when we are still on the head inode
(previously, releasing the rdlock twiddled the state, the client didn't
get say Frc, and hung indefinitely).
