Bug #4060
closed
mds: vxattr ceph.file.layout.pool doesn't check latest osdmap
Added by Sam Lang about 11 years ago.
Updated about 11 years ago.
Description
touch foo
create pool d2
setfattr -n ceph.file.layout.pool -v d2 foo
returns EINVAL
The problem is that the pool is created after the file, so the mds never does anything with objecter to trigger a new osdmap being sent (maybe_request_map()). I think we can request a new map, but don't wait if we don't get anything newer than what we have.
- Status changed from New to Rejected
You need to add it to the MDSMap first ("ceph mds add datapool [x]" or something), and the server does at least wait until it has an MDSMap which matches the client's — that shouldn't be a lag time you'll be able to see. :)
- Status changed from Rejected to In Progress
Even with add_data_pool I get EINVAL, so I'm reopening this. I've verified that (as before), the osdmap on the mds doesn't have the pool just created (and added with add_data_pool).
- Status changed from In Progress to Fix Under Review
Pushed a proposed fix to wip-4060. Needs review.
Also, I've tested this fix with a basic script:
set -e
mnt=$1
touch ${mnt}/foo.$$
rados mkpool foo.$$
poolid=$(ceph osd dump | grep "^pool" | awk '{print $2}' | tail -n 1)
ceph mds add_data_pool ${poolid}
touch ${mnt}/bar.$$
echo "setfattr -n ceph.file.layout.pool -v foo.$$ ${mnt}/foo.$$"
setfattr -n ceph.file.layout.pool -v foo.$$ ${mnt}/foo.$$
- Status changed from Fix Under Review to Resolved
commit:a04c01f6822b165bf339d41eda29fcc5fa555f53
Also available in: Atom
PDF