* in addition to the -march=foobar, we also need to pass -DFOOBAR to
gf-complete sources' cflags, so that the SIMD instructions can be
generated as expected.
* also extract the compiler support for instruction extensions detections
into SIMDExt.cmake.
* and only check the compiler support if CMAKE_SYSTEM_PROCESSOR matches
with the instruction-set/arch to be checked.
Jeff Layton [Thu, 1 Sep 2016 22:49:46 +0000 (18:49 -0400)]
SQUASH: client: querying for stx_version field requires getting all shared caps
Otherwise, someone could potentially query for just CEPH_STATX_VERSION,
and see it as unchanged, even when there are changes buffered up on
other clients.
By doing this, I don't think we'll incur any perf hit in the common use
case which is ganesha querying for all attributes. We are adding Xs
here, but unless there is a lot of xattr activity I don't think that
will generally cause a lot of exclusive cap recalls.
Also, we don't actually need AUTH caps to fetch CEPH_STATX_RDEV, remove
that from statx_to_mask. PIN is sufficient there.
Jeff Layton [Thu, 1 Sep 2016 15:16:06 +0000 (11:16 -0400)]
SQUASH: client: always take a change_attr update from the server if it's newer
I think this is more correct in the client. If we see a newer
change_attr, then we always want to take note of that fact, even if
we have the right caps.
I don't think this is necessary. We don't necessarily need to increment
the change attribute on every change, as long as we ensure that it gets
bumped iff there were changes since the last time you queried for it.
IOW: it's ok to have a single change_attr change encompass a large set
of changes, as long as you ensure that that it is larger by at least 1
after all of those changes.
In order to look at (and potentially cache) other attributes under that
change_attribute (e.g. owner or mode), you need to recall any outstanding
exclusive caps for those attrs. That causes their change_attrs to be
synched to the largest, which is enough to ensure that it changed in
some way.
os/bluestore: don't over-gift if bluefs free is smaller than bluestore_bluefs_min
- If free space of bluefs is smaller than bluestore_bluefs_min, then raise it
exactly up to bluestore_bluefs_min.
- Pre-check if bluestore_bluefs_min will exceed bluestore_bluefs_max_ratio * bluefs_total,
so if free space of bluefs is smaller than bluestore_bluefs_min_ratio * bluefs_total,
we'll still be able to gift.
xie xingguo [Wed, 31 Aug 2016 02:47:50 +0000 (10:47 +0800)]
os/bluestore/bluefs: drop redundant eof check for read_random()
Because we have done the sanity check and fixed the length
at the entrance, so we don't have to check it again,
especially in the while loop, which is less efficient.
xie xingguo [Tue, 30 Aug 2016 07:37:46 +0000 (15:37 +0800)]
os/bluestore/bluefs: use map to track dirty files
So dirty files are arranged by dirty_seq and then
those of same dirty_seq are grouped into list and
as a result we can clean up dirty files much faster
during _flush_and_sync_log().
Kefu Chai [Tue, 30 Aug 2016 05:33:24 +0000 (13:33 +0800)]
cmake: replace Findlttng-ust.cmake with FindLTTngUST.cmake
find_package(lttng-ust REQUIRED) fails to find the lttng library without
this change. because find_path(LTTNG_LIBRARY_DIR ...) does not search
in the default library paths. and the second mode of
FIND_PACKAGE_HANDLE_STANDARD_ARGS() does not stop the cmake with a fatal
message, even some of the required vars are missing. so use the
implemetantion from cmake upstream.
Sage Weil [Mon, 29 Aug 2016 19:15:06 +0000 (15:15 -0400)]
messages/MOSDMap: mark as enlighten OSDMap encoder
Back in 70094407c184baaf963577cc0d98edde12e8e9da we require that anyone
encoding an OSDMap pass in a special feature bit indicating that they are
'enlightened' and understand the rules around encoding OSDMaps (basically,
only mons get to do it). We forgot to update MOSDMap, which may have to
reencode an OSDMap without some features to talk to a really old client.
We haven't noticed until now because the old set of features we had to do
this for are really old.
We are about to introduce new features (for addr2 encoding) that change
that, and this fix is needed to prevent an assert when doing a reencode.
Jan Fajerski [Wed, 29 Jun 2016 07:40:07 +0000 (09:40 +0200)]
install-deps.sh: initial distro detection based on /etc/os-release
This avoids initial distribution detection (before lsb_release is available)
based on the presence of a specific package manager. This caused an
issue with openSUSE Tumbleweed before since both zypper and apt-get are
available.
Jeff Layton [Mon, 29 Aug 2016 11:16:41 +0000 (07:16 -0400)]
client: add the ability to set the btime
This adds a new set of libcephfs calls: ceph_ll_setattrx and
ceph_setattrx. This allows clients to set the btime in addition to other
values that are typically settable via ceph_setattr calls.
Currently, the setattrx mask uses the same CEPH_SETATTR values that the
ceph_setattr interface uses. I'm not sure this is what we will want
though. Would it be better to rephrase that via STATX_* constants?
Jeff Layton [Mon, 29 Aug 2016 11:16:41 +0000 (07:16 -0400)]
MDS: allow the MDS to accept requests to set the btime
Unfortunately, the only option here is to rev the MClientRequest
version as the ceph_mds_request_head is not currently versioned. Add a
new ceph_mds_request_head, which contains a new ceph_mds_request_args
structure.
The new ceph_mds_request_head is now versioned via a __le16
at the beginning of it, and then the args structure is expanded to hold
the btime. When we get a legacy ceph_mds_request_head, we just set the
new fields to zero. When encoding a reply to a legacy client, we simply
don't encode the version in the head, or the btime in the setattr union
member.
Reluctantly-Signed-off-by: Jeff Layton <jlayton@redhat.com>
Jeff Layton [Mon, 29 Aug 2016 11:16:40 +0000 (07:16 -0400)]
cephfs: rename ceph_mds_request_head and _args with a _legacy postfix
We're going to need to introduce new versions of these structures in
order to expand the setattr union member. Rename the existing ones so
that it's clear that they are for legacy clients and servers.
Jeff Layton [Mon, 29 Aug 2016 11:16:40 +0000 (07:16 -0400)]
mds: make frag_info_t add_dirty() function take a pointer to touched_mtime
...rather than messing around with references. While we're at it, we
can also make the argument optional, which allows us to drop an unused
stack variable from CDir::split.
Jeff Layton [Mon, 29 Aug 2016 11:16:40 +0000 (07:16 -0400)]
mds/client: bump the change_attr at the appropriate time for files
The semantics for a change_attr are that it should be incremented
whenever there is a change to the ctime in the inode. Add those
increments for the simple case of regular files. Directories however can
be fragmented so we'll need to do something more elaborate there.
Jeff Layton [Mon, 29 Aug 2016 14:33:10 +0000 (10:33 -0400)]
mds: ensure that change_attr reflects metadata changes on clients that hold CAP_FILE_EXCL
Suppose we have two clients. client1 holds FILE_EXCL cap and client2
holds AUTH_EXCL. Both have the change_attr at the same value (call it
1). client1 does 2 writes and its change_attr goes to 3. The client1
then queries for the change_attr and gets back 3 from the cache. The MDS
then recalls FILE_EXCL from client1 and now the MDS and client1 have the
same change_attr (3).
client2 then does a chmod on the file, and its change_attr goes to 2.
client1 then does a statx with STX_VERSION|STX_MODE. The MDS recalls the
AUTH_EXCL cap from client2, the change_attr in the MClientCaps is less
than the one in the MDS inode, so it gets discarded. client1 then sees
a new mode but the change_attr value has not changed, which violates the
rules.
Fix this with an extra increment of the MDS copy of the change_attr when
the caps being returned are dirty, and they don't contain exclusive write
caps.
projects / ceph.git / log