During recovery, we can clone subsets if we know that all clones will be
present. We skip this on caching pools because they may not be; do the
same when INCOMPLETE_CLONES is set.
Signed-off-by: Sage Weil <sage@redhat.com>
When scrubbing, do not complain about missing cloens when we are in a
caching mode *or* when the INCOMPLETE_CLONES flag is set. Both are
indicators that we may be missing clones and that that is okay.
Fixes: #8882
Signed-off-by: Sage Weil <sage@redhat.com>
Set a flag on the pg_pool_t when we change cache_mode NONE. This
is because object promotion may promote heads without all of the clones,
and when we switch the cache_mode back those objects may remain. Do
this on any cache_mode change (to or from NONE) to capture legacy
pools that were set up before this flag existed.
Signed-off-by: Sage Weil <sage@redhat.com>
If we have a pending pool value but the cache_mode hasn't changed, this is
still a no-op (and we don't need to block).
Backport: firefly
Signed-off-by: Sage Weil <sage@redhat.com>
mon: AuthMonitor: always encode full regardless of keyserver having keys
Reviewed-by: Gregory Farnum <greg@inktank.com>
Reviewed-by: Sage Weil <sage@redhat.com>
This is getting the NAME_MAX from the OS, but in reality the backend
KV store is the limiter. And for leveldb, there is no real limit.
Return 4096 for now.
Signed-off-by: Sage Weil <sage@redhat.com>
This backend can be used to create one global namespace for multiple
RGW regions.
Using a CNAME DNS response the traffic is directed towards the RGW region
without using HTTP redirects.
On clusters without cephx, assuming an admin never added a key to the
cluster, the monitors have empty key servers. A previous patch had the
AuthMonitor not encoding an empty keyserver as a full version.
As such, whenever the monitor restarts we will have to read the whole
state from disk in the form of incrementals. This poses a problem upon
trimming, as we do every now and then: whenever we start the monitor, it
will start with an empty keyserver, waiting to be populated from whatever
we have on disk. This is performed in update_from_paxos(), and the
AuthMonitor's will rely on the keyserver version to decide which
incrementals we care about -- basically, all versions > keyserver version.
Although we started with an empty keyserver (version 0) and are expecting
to read state from disk, in this case it means we will attempt to read
version 1 first. If the cluster has been running for a while now, and
even if no keys have been added, it's fair to assume that version is
greater than 0 (or even 1), as the AuthMonitor also deals and keeps track
of auth global ids. As such, we expect to read version 1, then version 2,
and so on. If we trim at some point however this will not be possible,
as version 1 will not exist -- and we will assert because of that.
This is fixed by ensuring the AuthMonitor keeps track of full versions
of the key server, even if it's of an empty key server -- it will still
keep track of the key server's version, which is incremented each time
we update from paxos even if it is empty.
Fixes: #8851
Backport: dumpling, firefly
Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
tx buffers need to go on the bh_lru_rest as well, and removing erases
(not inserts) them into dirty_or_tx_bh.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
The else-if chain here was wrong. Handling dirty or tx buffers and
errors should be in independent conditions.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Librbd will calculate max dirty object according to rbd_cache_max_size, it
doesn't suitable for every case. If user set image order 24, the calculating
result is too small for reality. It will increase the overhead of trim call
which is called each read/write op.
Now we make it as option for tunning, by default this value is calculated.
Signed-off-by: Haomai Wang <haomaiwang@gmail.com>
Flush op in ObjectCacher will iterate the whole active object set, each
dirty object also may own several BufferHead. If the object set is large,
it will consume too much time.
Use dirty_bh instead to reduce overhead. Now only dirty BufferHead will
be checked.
Signed-off-by: Haomai Wang <haomaiwang@gmail.com>
We were not properly setting up Sessions on the local_connection for
fast_dispatch'ed Messages if the cluster_addr was set explicitly: the OSD
was not in the dispatch list at bind() time (in ceph_osd.cc), and nothing
called it later on. This issue was missed in testing because Inktank only
uses unified NICs.
That led to errors like the following:
When do ec-read, i met a bug which was occured 100%. The messages are:
2014-07-14 10:03:07.318681 7f7654f6e700 -1 osd/OSD.cc: In function
'virtual void OSD::ms_fast_dispatch(Message*)' thread 7f7654f6e700 time
2014-07-14 10:03:07.316782 osd/OSD.cc: 5019: FAILED assert(session)
ceph version 0.82-585-g79f3f67 (79f3f67491)
1: (OSD::ms_fast_dispatch(Message*)+0x286) [0x6544b6]
2: (DispatchQueue::fast_dispatch(Message*)+0x56) [0xb059d6]
3: (DispatchQueue::run_local_delivery()+0x6b) [0xb08e0b]
4: (DispatchQueue::LocalDeliveryThread::entry()+0xd) [0xa4a5fd]
5: (()+0x8182) [0x7f7665670182]
6: (clone()+0x6d) [0x7f7663a1130d]
NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this.
To resolve this, we have the OSD invoke ms_handle_fast_connect() explicitly
in send_boot(). It's not really an appropriate location, but we're already
doing a bunch of messenger twiddling there, so it's acceptable for now.
Signed-off-by: Ma Jianpeng <jianpeng.ma@intel.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
osd: add config for osd_max_object_name_len = 2048 (was hard-coded at 4096)
Reviewed-by: Haomai Wang <haomaiwang@gmail.com>
and the first patch was
Reviewed-by: Samuel Just <sam.just@inktank.com>
Our max object name is not limited by file name size, but by the length of
the name we can stuff in an xattr. That will vary from file system to
file system, so just make this 4096. In practice, it should be limited
via the global tunable, if it is adjusted at all.
Signed-off-by: Sage Weil <sage@redhat.com>
As part of issue #8858, and to be more in line with S3, dump the Prefix
field when listing bucket even if bucket is empty.
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
To be more in line with the S3 api. Beforehand we didn't account the
common prefixes towards the MaxKeys (a single common prefix counts as a
single key). Also need to adjust the marker now if it is pointing at a
common prefix.
Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
Make standby-replay MDSes much more careful about journal formats; both changing them and generally being aware.
Reviewed-by: Greg Farnum <greg@inktank.com>
If found a prefix, calculate a string greater than that so that next
request we can skip to that. This is still not the most efficient way to
do it. It'll be better to push it down to the objclass, but that'll
require a much bigger change.
Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
Set a limit on the length of an attr name. The fs can only take 128
bytes, but we were not imposing any limit.
Add a test.
Reported-by: Haomai Wang <haomaiwang@gmail.com>
Signed-off-by: Sage Weil <sage@inktank.com>
Most importantly, capture that attrs on FileStore can't be more than about
100 chars. The Linux xattrs can only be 128 chars, but we also have some
prefixing we do.
Signed-off-by: Sage Weil <sage@redhat.com>
Previously we had a hard coded limit of 4096. Objects > 3k crash the OSD
when running on ext4, although they probably work on xfs. But rgw only
generates objects a bit over 1024 bytes (maybe 1200 tops?), so let set a
more reasonable limit here. 2048 is a nice round number and should be
safe.
Add a test.
Fixes: #8174
Signed-off-by: Sage Weil <sage@redhat.com>
