Hi,
On 7/4/19 3:00 PM, Stefan Kooman wrote:
> - Only backport fixes that do not introduce new functionality, but addresses
> (impaired) functionality already present in the release.
ack, and also my full agrement/support for everything else you wrote,
thanks.
reading in the changelogs about
On 6/18/19 3:39 PM, Paul Emmerich wrote:
> we maintain (unofficial) Nautilus builds for Buster here:
> https://mirror.croit.io/debian-nautilus/
the repository doesn't contain the source packages. just out of
curiosity to see what you might have changes, apart from just
(re)building the packages..
On 6/18/19 3:11 PM, Tobias Gall wrote:
> I would like to switch to debian buster and test the upgrade from
> luminous but there are currently no ceph releases/builds for buster.
shameless plug:
we're re-building ceph packages in our repository that we do for our
university (and a few other
Hi,
I didn't bother to create a twitter account just to be able to
participate in the poll.. so.. please count me in for October.
Regards,
Daniel
___
ceph-users mailing list
ceph-users@lists.ceph.com
On 6/6/19 9:26 AM, Xiaoxi Chen wrote:
> I will vote for November for several reasons:
[...]
as an academic institution we're aligned by August to July (school year)
instead of the January to December (calendar year), so all your reasons
(thanks!) are valid for us.. just shifted by 6 months,
On 6/5/19 5:57 PM, Sage Weil wrote:
> So far the balance of opinion seems to favor a shift to a 12 month
> cycle [...] it seems pretty likely we'll make that shift.
thanks, much appreciated (from an cluster operating point of view).
> Thoughts?
GNOME and a few others are doing April and
On 01/04/2019 07:32 PM, Peter Woodman wrote:
> not to mention that the current released version of mimic (.2) has a
> bug that is potentially catastrophic to cephfs, known about for
> months, yet it's not in the release notes. would have upgraded and
> destroyed data had i not caught a thread on
On 01/04/2019 05:07 PM, Matthew Vernon wrote:
> how is it still the case that packages are being pushed onto the official
> ceph.com repos that people
> shouldn't install?
We're still on 12.2.5 because of this. Basically every 12.2.x after that
had notes on the mailinglist like "don't use, wait
Hi,
On 11/21/2018 07:04 PM, Rodrigo Embeita wrote:
> Reduced data availability: 7 pgs inactive, 7 pgs down
this is your first problem: unless you have all data available again,
cephfs will not be back.
after that, I would take care about the redundancy next, and get the one
missing
Hi,
On 10/17/2018 04:04 PM, John Spray wrote:
> If there isn't anything
> too hacky involved in the build perhaps your packages could simply be
> the official ones?
being a Debian Developer, I can upload my backports that I maintain/use
at work to e.g. people.debian.org/~daniel or so. Given time
On 07/17/2018 11:43 AM, Marc Roos wrote:
> I had similar thing with doing the ls. Increasing the cache limit helped
> with our test cluster
same here; additionally we also had to use more than one MDS to get good
performance (currently 3 MDS plus 2 stand-by per FS).
Regards,
Daniel
On 07/09/2018 10:18 AM, Manuel Sopena Ballesteros wrote:
> FUSE is supposed to run slower.
in our tests with ceph 11.2.x and 12.2.x clusters, cephfs-fuse is always
around 10 times slower than kernel cephfs.
Regards,
Daniel
___
ceph-users mailing list
Hi,
On 05/24/2018 02:53 PM, David Disseldorp wrote:
>> [ceph_test]
>> path = /ceph-kernel
>> guest ok = no
>> delete readonly = yes
>> oplocks = yes
>> posix locking = no
jftr, we use the following to disable all locking (on samba 4.8.2):
oplocks = False
level2 oplocks = False
kernel
Hi,
I coudn't agree more, but just to re-emphasize what others already said:
the point of replica 3 is not to have extra safety for
(human|software|server) failures, but to have enough data around to
allow rebalancing the cluster when disks fail.
after a certain amount of disks in a
Hi
On 05/21/2018 05:38 PM, Jake Grimmett wrote:
> Unfortunately we have a large number (~200) of Windows and Macs clients
> which need CIFS/SMB access to cephfs.
we too, which is why we're (partially) exporting cephfs over samba too,
1.5y in production now.
for us, cephfs-over-samba is
On 05/19/2018 01:13 AM, Webert de Souza Lima wrote:
> New question: will it make any difference in the balancing if instead of
> having the MAIL directory in the root of cephfs and the domains's
> subtrees inside it, I discard the parent dir and put all the subtress right
> in cephfs root?
the
On 05/18/2018 11:19 PM, Patrick Donnelly wrote:
> So, you would want to have a standby-replay
> daemon for each rank or just have normal standbys. It will likely
> depend on the size of your MDS (cache size) and available hardware.
jftr, having 3 active mds and 3 standby-replay resulted May 20217
On 04/27/2018 07:11 PM, Patrick Donnelly wrote:
> The answer is that there may be partial availability from
> the up:active ranks which may hand out capabilities for the subtrees
> they manage or no availability if that's not possible because it
> cannot obtain the necessary locks.
additionally:
ceph is cluster - so reboots aren't an issue (we do set noout during a
planed serial reboot of all machines of the cluster).
personally i don't think the hassle of live patching is worth it. it's a
very gross hack that only works well in very specific niche cases. ceph
(as every proper cluster)
Hi,
On 01/19/18 14:46, Youzhong Yang wrote:
> Just wondering if anyone has seen the same issue, or it's just me.
we're using debian with our own backported kernels and ceph, works rock
solid.
what you're describing sounds more like hardware issues to me. if you
don't fully "trust"/have
Hi,
On 12/05/17 17:58, Dan Jakubiec wrote:
> Is this is configuration problem or a bug?
we had massive problems with both kraken (feb-sept 2017) and luminous
(12.2.0), seeing the same behaviour as you. ceph.conf was containing
defaults only, except that we had to crank up mds_cache_size and
On 11/30/17 14:04, Fabian Grünbichler wrote:
> point is - you should not purposefully attempt to annoy users and/or
> downstreams by changing behaviour in the middle of an LTS release cycle,
exactly. upgrading the patch level (x.y.z to x.y.z+1) should imho never
introduce a behaviour-change,
On 11/29/17 00:06, Nigel Williams wrote:
> Are their opinions on how stable multiple filesystems per single Ceph
> cluster is in practice?
we're using a single cephfs in production since february, and switched
to three cephfs in september - without any problem so far (running 12.2.1).
workload
On 11/28/17 15:09, Geoffrey Rhodes wrote:
> I'd like to run more than one Ceph file system in the same cluster.
> Can anybody point me in the right direction to explain how to mount the
> second file system?
if you use the kernel client, you can use the mds_namespace option, i.e.:
mount -t
On 10/10/2017 02:10 PM, John Spray wrote:
> Yes.
worked, rank 6 is back and cephfs up again. thank you very much.
> Do a final ls to make sure you got all of them -- it is
> dangerous to leave any fragments behind.
will do.
> BTW opened http://tracker.ceph.com/issues/21749 for the underlying
Hi John,
thank you very much for your help.
On 10/10/2017 12:57 PM, John Spray wrote:
> A) Do a "rados -p ls | grep "^506\." or similar, to
> get a list of the objects
done, gives me these:
506.
506.0017
506.001b
506.0019
506.001a
506.001c
Hi all,
unfortunatly I'm still struggling bringing cephfs back up after one of
the MDS has been marked "damaged" (see messages from monday).
1. When I mark the rank as "repaired", this is what I get in the monitor
log (leaving unrelated leveldb compacting chatter aside):
2017-10-10
Hi John,
On 10/09/2017 10:47 AM, John Spray wrote:
> When a rank is "damaged", that means the MDS rank is blocked from
> starting because Ceph thinks the on-disk metadata is damaged -- no
> amount of restarting things will help.
thanks.
> The place to start with the investigation is to find the
On 10/09/2017 09:17 AM, Daniel Baumann wrote:
> The relevant portion from the ceph-mds log (when starting mds9 which
> should then take up rank 6; I'm happy to provide any logs):
i've turned up the logging (see attachment).. could it be that we hit
this bug here?
http://tracker.ceph.com/
Hi all,
we have a Ceph Cluster (12.2.1) with 9 MDS ranks in multi-mds mode.
"out of the blue", rank 6 is marked as damaged (and all other MDS are in
state up:resolve) and I can't bring the FS up again.
'ceph -s' says:
[...]
1 filesystem is degraded
1 mds daemon damaged
30 matches
Mail list logo
