- ceph-users - lists.ceph.io

test requested y Anthony Middleton
by zouhair nador 02 Jun '26

02 Jun '26

Hello [cid:d40f5272-f460-403e-be1b-ca2561377aed]

1 1

CFP: PDSW 2026 @ SC26 - Submission Deadline July 31, 2026
by Neuwirth, Prof. Dr. Sarah 02 Jun '26

02 Jun '26

-------------------------------------------------------------------------- The 11th International Parallel Data Systems Workshop (PDSW'26) -------------------------------------------------------------------------- PDSW 2026 website: https://www.pdsw.org/ Paper Submissions due: July 31st, 2026, 11:59 PM AoE AD due: August 7th, 2026, 11:59 PM AoE Paper Notification: Sep 4th, 2026, 11:59 PM AoE Camera ready due: Sep 25th, 2026, 11:59 PM AoE Final AD/AE due: Sep 25th, 2026, 11:59 PM AoE Workshop day: Monday, Nov 16th, 2026 (all day) Submissions website: https://submissions.supercomputing.org/ We are excited to announce the 11th International Parallel Data Systems Workshop (PDSW'26), to be held in conjunction with SC26: The International Conference for High Performance Computing, Networking, Storage, and Analysis, in Chicago, IL. PDSW'26 builds upon the rich legacy of its predecessor workshops, the Petascale Data Storage Workshop (PDSW, 2006–2015) and the Data Intensive Scalable Computing Systems (DISCS, 2012–2015) workshop. The increasing importance of efficient data storage and management continues to drive scientific productivity across traditional simulation-based HPC environments and emerging Cloud, AI/ML, and Big Data analysis frameworks. Challenges are compounded by the rapidly expanding volumes of experimental and observational data, the growing disparity between computational and storage hardware performance, and the rise of novel data-driven algorithms in machine learning. This workshop aims to advance research and development by addressing the most pressing challenges in large-scale data storage and processing. We invite the community to contribute original research manuscripts that introduce and evaluate novel algorithms or architectures, share significant scientific case studies or workloads, or assess the reproducibility of previously published work. We emphasize the importance of community collaboration for problem identification, workload capture, solution interoperability, standardization, and shared tools. Authors are encouraged to provide comprehensive experimental environment details (software versions, benchmark configurations, etc.) to promote transparency and facilitate collaborative progress. ----------------------------- Topics of Interest ----------------------------- - Scalable Architectures: Distributed data storage, archival, and virtualization. - New Data Processing Models and Algorithms: Application of innovative data processing models and algorithms for parallel computing and analysis. - Performance Analysis: Benchmarking, resource management, and workload studies. - Cloud and Container-Based Models: Enabling cloud and container-based frameworks for large-scale data analysis. - Storage Technologies: Adaptation to emerging hardware and computing models. - Data Integrity: Techniques to ensure data integrity, availability, reliability, and fault tolerance. - Programming Models and Frameworks: Big data solutions for data-intensive computing. - Hybrid Cloud Data Processing: Integration of hybrid cloud and on-premise data processing. - Cloud-Specific Opportunities: Data storage and transit opportunities specific to cloud computing. - Storage System Programmability: Enhancing programmability in storage systems. - Data Reduction Techniques: Filtering, compression, and reduction techniques for large-scale data. - File and Metadata Management: Parallel file systems, metadata management at scale. - In-Situ and In-Transit Processing: Integrating computation into the memory and storage hierarchy for in-situ and in-transit data processing. - Alternative Storage Models: Object stores, key-value stores, and other data storage models. - Productivity Tools: Tools for data-intensive computing, data mining, and knowledge discovery. - Data Movement: Managing data movement between compute and data-intensive components. - Cross-Cloud Data Management: Efficient data management across different cloud environments. - AI-enhanced Systems: Storage system optimization and data analytics using machine learning. - New Memory and Storage Systems: Innovative techniques and performance evaluation for new memory and storage systems. - AI and Agentic related data management: tools and techniques necessary to support AI workloads and Agentic AI data analytics for online decision making. More details are available at: https://www.pdsw.org/ ----------------------------- Template and Submission ----------------------------- - A full paper up to 6 pages in length, excluding references, acknowledgements, and AD/AE appendices. Once anonymization is removed for camera ready submission, these limits must still be met. Please make sure that author names fit within the 6-page limit as well even though the submission should be double-anonymized. - Artifact Description (AD) Appendix is mandatory and Artifact Evaluation (AE) Appendix is optional. - Papers must adhere to the IEEE conference proceeding template available at: https://www.ieee.org/conferences/publishing/templates - Papers will be reviewed double-blind. Author names and affiliations should NOT be included in the submitted paper. - Submit your papers by July 31st, 2026, 11:59 PM AoE at https://submissions.supercomputing.org/ ----------------------------- Reproducibility Initiative ----------------------------- Aligned with the SC26 Reproducibility Initiative (https://sc26.supercomputing.org/program/papers/reproducibility-initiative/) we require detailed and structured artifact descriptions (AD) using the SC26 format (https://github.com/jennfshr/sc26-repro) The AD should include a field for one or more links to data (Zenodo, figshare, etc.) and code (Github, GitLab, Bitbucket, etc.) repositories. For the artifacts that will be placed in the code repository, we encourage authors to follow the PDSW 2026 Reproducibility Addendum (https://www.pdsw.org/pdsw26/PDSW2026ReproducibilityInitiativeAddendum.pdf) on how to structure the artifact, as it will make it easier for the reviewing committee and readers of the paper in the future. Submissions website: https://submissions.supercomputing.org/ ----------------------------- Organization Team ----------------------------- General Chair: Jay Lofstead Sandia National Laboratories, USA Program Co-Chairs: Sarah Neuwirth Johannes Gutenberg University Mainz, Germany Lipeng Wan Georgia State University, USA Reproducibility Chair: Ricardo Macedo INESC TEC & University of Minho, Portugal Publicity Chair Radita Liem Johannes Gutenberg University Mainz, Germany Web & Publications Chair: Joan Digney Carnegie Mellon University, USA -------------------------------------------------------------------------------- Univ.-Prof. Dr. Sarah M. Neuwirth Co-Director, NHR South-West HPC Center Research Group Head, High Performance Computing and its Applications Johannes Gutenberg University Mainz Anselm-Franz-von-Bentzelweg 12 55099 Mainz | Germany Office: ZDV, Room 01-339 Phone: +49 6131 39 23643 Email: neuwirth(a)uni-mainz.de<mailto:neuwirth@uni-mainz.de> Website: https://www.hpca-group.de/ NHR@SW Website: https://nhrsw.de/ --------------------------------------------------------------------------------

1 0

June Ceph Developer Meetup
by Anthony Middleton 01 Jun '26

01 Jun '26

Hey Ceph Friends, I hope your week is off to a good start. Just a reminder that the next Ceph Developer Monthly Meetup is this Wednesday, June 3rd, at 8 am PDT. RSVP here: https://www.meetup.com/ceph-user-group/events/315060630/ Be sure to add your topic to the meeting tracker: https://tracker.ceph.com/projects/ceph/wiki/CDM_03_JUN_2026 Best, ------- Anthony Middleton Community Manager, Ceph Foundation amiddleton(a)linuxfoundation.org LinkedIn <https://www.linkedin.com/company/ceph>| BlueSky <https://bsky.app/profile/ceph.io> | Twitter <https://x.com/Ceph>

1 0

Re: Integrating OSDs from a previous Ceph installation
by Jacek Rużyczka 01 Jun '26

01 Jun '26

Hi, I must have followed the wrong instructions (as often seems to be the case when it comes to Ceph). I gave Ceph another try with --fsid, and then it worked. A missing fsid file cost me an hour, but the OSD subfolder seems to be OK now: mixtile@blade3n1:~$ sudo ls -al /var/lib/ceph/8aad3073-39a1-11f1-bf6e-f2704a1efa 9b/osd.2 total 16 drwxr-xr-x 2 ceph ceph 4096 Jun 1 16:50 . drwx------ 14 167 167 4096 Jun 1 13:47 .. lrwxrwxrwx 1 ceph ceph 93 Jun 1 16:44 block -> /dev/ceph-81bc1761-e8f6-446c- 96f3-eb1b8f92628b/osd-block-9f7fd40d-0698-40b9-8718-62942b03e263 -rw-r--r-- 1 ceph ceph 37 Jun 1 16:50 fsid In the meantime, I've managed to issue this command: sudo ceph-volume lvm activate --all There's one problem though: I get the feedback that ceph-osd@2 is working, but sudo systemctl status ceph-osd@2 says that the daemon failed to start: Jun 01 18:57:43 blade3n1 ceph-osd[317772]: 2026-06-01T18:57:43.403+0200 ffffb584 9040 -1 osd.2 7314 init authentication failed: (13) Permission denied What puzzles me: Why is the OSD daemon started as a normal service and not as a Docker container? Am So., 31. Mai 2026 um 21:27 Uhr schrieb Eugen Block via ceph-users < ceph-users(a)ceph.io>: > I don't see the '--fsid' flag in your command, it needs to be part of > the bootstrap command. So 'cephadm bootrap --mon-ip IP --fsid FSID' > and so on. > > 4 OSDs istn't that much, it should be doable in a reasonable amount of > time. It took me around two hours to bring my test cluster with 3 OSDs > back up, I think. > > > /var/lib/ceph/osd/ceph-2 > > This is the view from within the cephadm shell, the directory on the > filesystem is : > > /var/lib/ceph/{FSID}/osd.2 > > which is then mapped into the container. > > Zitat von Jacek Rużyczka <jacek.ruzyczka(a)googlemail.com>: > > >> > >> No, the data is not inaccessible until you wipe the OSDs. > > > > > > Ah, that's good to know that at least the data are still there. > > > > How many OSDs are we talking about here? > > > > > > I've got 4 OSDs, which hold 1.3 TB of data in total. I do have a backup > of > > them on an external HDD, which spit out a handful of warnings during the > > last restore, so destroying the previous SSD, creating new ones, and > trying > > another restore are things I'd like to avoid. > > > > And regarding the fsid, you can specify it in the bootstrap command, > >> you won’t be able to change it afterwards. > > > > > > This is exactly what I tried to do: > > > > sudo cephadm bootstrap --mon-ip $MYIP --config /etc/ceph/ceph.conf~~ > > --allow-overwrite > > > > And /etc/ceph/ceph.conf~~ contains the old FSID: > > > > # minimal ceph.conf for 8aad3073-39a1-11f1-bf6e-f2704a1efa9b > > [global] > > fsid = 8aad3073-39a1-11f1-bf6e-f2704a1efa9b > > mon_host = [v2:10.20.0.11:3300/0,v1:10.20.0.11:6789/0] [v2: > > 10.20.0.12:3300/0,v1:10.20.0.12:6789/0] [v2: > > 10.20.0.13:3300/0,v1:10.20.0.13:6789/0] [v2: > > 10.20.0.14:3300/0,v1:10.20.0.14:6789/0] > > > > Nevertheless, cephadm ignored the old settings and gave the new cluster > a > > generated ID. So I've gotta tear down the cluster and start again? What > > about the key pairs stored in /etc/ceph? > > > > You can simply create the OSD directories and create a symbolic link to > >> the block device. Cephadm simply maps it then. > > > > > > I've now recreated the dir /var/lib/ceph/osd/ceph-2 and have to symlink > > /dev/ceph-81bc1761-e8f6-446c-96f3-eb1b8f92628b/o > > sd-block-9f7fd40d-0698-40b9-8718-62942b03e263 there? Or should ceph-2 be > > the name of the symlink? > > > > I recommend to hire a professional to help you out, just to be on the > safe > >> side. > > > > > > I've got a Ceph expert in our hackspace, but I'm not sure whether he can > > help me. > > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io >

2 1

Re: tentacle 20.2.2 QE validation status
by Patrick Donnelly 01 Jun '26

01 Jun '26

I've created a tracker for this bug: https://tracker.ceph.com/issues/77037 On Mon, Jun 1, 2026 at 3:57 AM Guillaume ABRIOUX via ceph-users <ceph-users(a)ceph.io> wrote: > > Hi Yuri, > > few tests in the orch/cephadm suite may be failing due to issues in their definitions: nvme-loop setup appears to be affected by nvme-cli behavior, see [1] and [2] > > [1] https://tracker.ceph.com/issues/76184 > [2] https://github.com/ceph/ceph/pull/68569/changes#r3332344141 > > > Thanks! > > -- > Guillaume Abrioux > Software Engineer > From: Yuri Weinstein via ceph-users <ceph-users(a)ceph.io> > Date: Tuesday, 26 May 2026 at 18:20 > To: dev <dev(a)ceph.io>; ceph-users <ceph-users(a)ceph.io> > Subject: [EXTERNAL] [ceph-users] tentacle 20.2.2 QE validation status > > Details of this release are summarized here: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tracker.ceph.com_issue… > > Release Notes - TBD > LRC upgrade - TBD > > Seeking approvals/reviews for: > > smoke: PASSED > > rados: Radek, Laura, Afreen, Travis > rgw: Adam Emerson > fs: Venky > orch/ceph-volume: Adam King & Guillaume > rbd: Ilya > krbd: Ilya > nvmeof: Aviv, Vallari > > upgrade: Patrick > > upgrade-clients:client-upgrade-reef-tentacle-tentacle: TBD > upgrade-clients:client-upgrade-squid-tentacle-tentacle: TBD > > perf-basic: PASSED > > crimson-rados: N/A > > powercycle: PASSED > > TIA > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io > > Unless otherwise stated above: > > Compagnie IBM France > Siège Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex > RCS Nanterre 552 118 465 > Forme Sociale : S.A.S. > Capital Social : 664 614 175,50 € > SIRET : 552 118 465 03644 - Code NAF 6203Z > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io > -- Patrick Donnelly, Ph.D. He / Him / His Red Hat Partner Engineer IBM, Inc. GPG: 19F28A586F808C2402351B93C3301A3E258DD79D

1 0

Re: tentacle 20.2.2 QE validation status
by Yuri Weinstein 01 Jun '26

01 Jun '26

Thx for the update, Guillaume Are those blockers? On Mon, Jun 1, 2026 at 1:02 AM Guillaume ABRIOUX via dev <dev(a)ceph.io> wrote: > Hi Yuri, > > few tests in the orch/cephadm suite may be failing due to issues in their > definitions: nvme-loop setup appears to be affected by nvme-cli behavior, > see [1] and [2] > > [1] https://tracker.ceph.com/issues/76184 > [2] https://github.com/ceph/ceph/pull/68569/changes#r3332344141 > > > Thanks! > > -- > Guillaume Abrioux > Software Engineer > *From: *Yuri Weinstein via ceph-users <ceph-users(a)ceph.io> > *Date: *Tuesday, 26 May 2026 at 18:20 > *To: *dev <dev(a)ceph.io>; ceph-users <ceph-users(a)ceph.io> > *Subject: *[EXTERNAL] [ceph-users] tentacle 20.2.2 QE validation status > > Details of this release are summarized here: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tracker.ceph.com_issue… > > Release Notes - TBD > LRC upgrade - TBD > > Seeking approvals/reviews for: > > smoke: PASSED > > rados: Radek, Laura, Afreen, Travis > rgw: Adam Emerson > fs: Venky > orch/ceph-volume: Adam King & Guillaume > rbd: Ilya > krbd: Ilya > nvmeof: Aviv, Vallari > > upgrade: Patrick > > upgrade-clients:client-upgrade-reef-tentacle-tentacle: TBD > upgrade-clients:client-upgrade-squid-tentacle-tentacle: TBD > > perf-basic: PASSED > > crimson-rados: N/A > > powercycle: PASSED > > TIA > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io > Unless otherwise stated above: > > Compagnie IBM France > Siège Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex > RCS Nanterre 552 118 465 > Forme Sociale : S.A.S. > Capital Social : 664 614 175,50 € > SIRET : 552 118 465 03644 - Code NAF 6203Z >

1 0

v19.2.4 Squid released
by Yuri Weinstein 01 Jun '26

01 Jun '26

This is the fourth minor release in the Squid series. We recommend that all users update to this release. Notable Changes --------------- OSD / BlueStore --------------- * BlueFS: Increased the default WAL volume size to 1GB to prevent ENOSPC failures. * Volume Selection: Fixed the usage of bluestore_volume_selection_reserved_factor and updated row naming conventions in RocksDBBlueFSVolumeSelector. * Health: Added a time_added field to mon_info_t to prevent freshly added monitors from incorrectly triggering a MON_DOWN health status. * Tooling: Updated monmaptool to correctly respect set features when adding addresses. RADOS / Manager (mgr) --------------------- * RADOS pybind: Fixed a parameter reversal bug in WriteOp.zero() where offset and length were swapped when calling the underlying C API. * Daemon Health: Modified the manager to clear health metrics for down or out OSDs instead of removing them entirely from the daemon state. * Autoscaler: Updated pg_autoscale_mode logic to accurately reflect the no_autoscale flag in both standard and JSON command outputs. RADOS Gateway (RGW) ------------------- * Notifications: Resolved a reserved_size drift in the 2pc_queue causing ENOSPC errors and fixed a leak where overhead was not properly decremented during commit/abort. * Multipart Uploads: Fixed an issue where tags could not be retrieved from objects created via multipart uploads. * Kafka Integration: Updated the internal Kafka version support to 3.9.2. CephFS / MDS ------------ * Fragments: Simplified fragment printing and corrected frag_t endianness conversion for network and storage consistency. * FUSE Client: Updated the FUSE client to clarify that fallocate disk space reservation is only supported with specific flags like FALLOC_FL_KEEP_SIZE. * Metadata: Updated the MDS to dump frag_t as an object and included sysinfo in the status command output for better diagnostics. Dashboard --------- * Services: Fixed a bug where changing MDS placement to a label incorrectly triggered the creation of an entirely new MDS service. * Access Control: Fixed role-based access control permissions and added missing types to the mgr-module list. librbd & rbd-mirror ------------------- * RBD: Introduced a new ``RBD_LOCK_MODE_EXCLUSIVE_TRANSIENT`` policy for ``rbd_lock_acquire()``. This is a low-level interface intended to allow a peer to grab exclusive lock manually for short periods of time with other peers pausing their activity and waiting for the lock to be released rather than instantly aborting I/O and returning an error. It's possible to switch from ``RBD_LOCK_MODE_EXCLUSIVE`` to ``RBD_LOCK_MODE_EXCLUSIVE_TRANSIENT`` policy and vice versa even if the lock is already held. We recommend users to update to this release. For detailed release notes with links & changelog please refer to the official blog entry at https://ceph.io/en/news/blog/2026/v19-2-4-squid-released/ Getting Ceph ------------ * Git at git://github.com/ceph/ceph.git * Tarball at https://download.ceph.com/tarballs/ceph-19.2.4.tar.gz * Containers at https://quay.io/repository/ceph/ceph * For packages, see https://docs.ceph.com/en/latest/install/get-packages/ * Release git sha1: 7cc0193a616a3333d22b7762037fa5b73a4d06a6

1 0

Re: Weird behavior for 2 OSDs in our cluster
by Wannes Smet 01 Jun '26

01 Jun '26

I think I know what happened. ceph -s reported `2 osds(s) are not reachable`. What I think happened is that during boot up of those 2 nodes the network bond on ceph-public might not have been up yet, while the network bond on the ceph-cluster network was up. Those 2 OSD containers were started anyway, probably only just before ceph-public was up. All the other OSD containers were started after the network stack was fully functional That explains all of the rest of my observations: * OSDs are still UP because heartbeating works (other bond was likely up). Cluster thinks all is well except for 2 OSDs "unreachable" * hence mgr does not report OSD down/out/reduced data availability, they're effectively not down indeed. * No mention of "reduced data availability" * Also matches with recovery not starting. Not OUT=no recovery. * Also matches with the VMs running on our Proxmox nodes (which use RBD from this cluster) were just stuck at very early boot. They probably neede a PG on either OSD.53/86 and kep trying because they didn't get a new clustermap. Wannes ________________________________ From: Eugen Block via ceph-users <ceph-users(a)ceph.io> Sent: Sunday, May 31, 2026 11:13 To: ceph-users(a)ceph.io <ceph-users(a)ceph.io> Subject: [ceph-users] Re: Weird behavior for 2 OSDs in our cluster Hi, the MGR doesn't always report the correct PG status, so don't rely on that too much. Sometimes it's necessary to restart primary OSDs for stuck PGs, although a repeer could have been sufficient. Your Ceph clients had to refresh their osdmap, ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Hi, the MGR doesn't always report the correct PG status, so don't rely on that too much. Sometimes it's necessary to restart primary OSDs for stuck PGs, although a repeer could have been sufficient. Your Ceph clients had to refresh their osdmap, that's when they notice that there had been down OSDs. It's not a real-time log in this case, no need to worry. It's a common question though, I think we also asked it 8 to 10 years ago. ;-) Regards, Eugen Zitat von Wannes Smet via ceph-users <ceph-users(a)ceph.io>: > Hi, > > I'm running a Ceph cluster 19.2.2, 23 nodes, 152 OSDs, cephadm > deployed. Most SAS SSDs, 12 NVMe SSDs. > > Yesterday we experienced a total power failure and everything went > down hard. Also our Ceph cluster. There were a couple of things, but > this stood out after it got back up: > > [ERR] OSD_UNREACHABLE: 2 osds(s) are not reachable > osd.53's public address is not in '192.168.11.0/24' subnet > osd.86's public address is not in '192.168.11.0/24' subnet > > ceph -s did not say reduced data {availability,redundancy} which is > a bit "off", given that both OSDs are in separate hosts, failure > domain=host. There must have been PGs with less than 3 replicas and > also PGs with just one replica left? > > So I manually restarted those OSDs with systemctl , a recovery > process started and all our VMs, "magically" started booting now. > I'm also surprised that the recovery process only started when those > OSDs got back up. > > I didn't make too much of the above, but now this morning, I'm > looking at the kernel ring buffer of our PVE nodes and I notice the > logs below. Just a single "blip". All at the same time on all of our > PVE nodes (ceph clients): > > [Sat May 30 22:03:46 2026] libceph > (e8020818-2100-11f0-8a12-9cdc71772100 e179035): osd53 down > [Sat May 30 22:03:46 2026] libceph > (e8020818-2100-11f0-8a12-9cdc71772100 e179050): osd53 up > [Sat May 30 22:03:46 2026] libceph > (e8020818-2100-11f0-8a12-9cdc71772100 e179057): osd86 down > [Sat May 30 22:03:46 2026] libceph > (e8020818-2100-11f0-8a12-9cdc71772100 e179074): osd86 up > > I don't see anything weird in the Ceph cluster itself, neither in > the log files of the ODS. > > I'm not sure what to make from this. Why would this happen and what > would you do? > > Thanks for your insights, > > Wannes Smet > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io _______________________________________________ ceph-users mailing list -- ceph-users(a)ceph.io To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Re: tentacle 20.2.2 QE validation status
by Guillaume ABRIOUX 01 Jun '26

01 Jun '26

Hi Yuri, few tests in the orch/cephadm suite may be failing due to issues in their definitions: nvme-loop setup appears to be affected by nvme-cli behavior, see [1] and [2] [1] https://tracker.ceph.com/issues/76184 [2] https://github.com/ceph/ceph/pull/68569/changes#r3332344141 Thanks! -- Guillaume Abrioux Software Engineer From: Yuri Weinstein via ceph-users <ceph-users(a)ceph.io> Date: Tuesday, 26 May 2026 at 18:20 To: dev <dev(a)ceph.io>; ceph-users <ceph-users(a)ceph.io> Subject: [EXTERNAL] [ceph-users] tentacle 20.2.2 QE validation status Details of this release are summarized here: https://urldefense.proofpoint.com/v2/url?u=https-3A__tracker.ceph.com_issue… Release Notes - TBD LRC upgrade - TBD Seeking approvals/reviews for: smoke: PASSED rados: Radek, Laura, Afreen, Travis rgw: Adam Emerson fs: Venky orch/ceph-volume: Adam King & Guillaume rbd: Ilya krbd: Ilya nvmeof: Aviv, Vallari upgrade: Patrick upgrade-clients:client-upgrade-reef-tentacle-tentacle: TBD upgrade-clients:client-upgrade-squid-tentacle-tentacle: TBD perf-basic: PASSED crimson-rados: N/A powercycle: PASSED TIA _______________________________________________ ceph-users mailing list -- ceph-users(a)ceph.io To unsubscribe send an email to ceph-users-leave(a)ceph.io Unless otherwise stated above: Compagnie IBM France Siège Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 614 175,50 € SIRET : 552 118 465 03644 - Code NAF 6203Z

1 0

Re: Integrating OSDs from a previous Ceph installation
by Jacek Rużyczka 31 May '26

31 May '26

> > No, the data is not inaccessible until you wipe the OSDs. Ah, that's good to know that at least the data are still there. How many OSDs are we talking about here? I've got 4 OSDs, which hold 1.3 TB of data in total. I do have a backup of them on an external HDD, which spit out a handful of warnings during the last restore, so destroying the previous SSD, creating new ones, and trying another restore are things I'd like to avoid. And regarding the fsid, you can specify it in the bootstrap command, > you won’t be able to change it afterwards. This is exactly what I tried to do: sudo cephadm bootstrap --mon-ip $MYIP --config /etc/ceph/ceph.conf~~ --allow-overwrite And /etc/ceph/ceph.conf~~ contains the old FSID: # minimal ceph.conf for 8aad3073-39a1-11f1-bf6e-f2704a1efa9b [global] fsid = 8aad3073-39a1-11f1-bf6e-f2704a1efa9b mon_host = [v2:10.20.0.11:3300/0,v1:10.20.0.11:6789/0] [v2: 10.20.0.12:3300/0,v1:10.20.0.12:6789/0] [v2: 10.20.0.13:3300/0,v1:10.20.0.13:6789/0] [v2: 10.20.0.14:3300/0,v1:10.20.0.14:6789/0] Nevertheless, cephadm ignored the old settings and gave the new cluster a generated ID. So I've gotta tear down the cluster and start again? What about the key pairs stored in /etc/ceph? You can simply create the OSD directories and create a symbolic link to > the block device. Cephadm simply maps it then. I've now recreated the dir /var/lib/ceph/osd/ceph-2 and have to symlink /dev/ceph-81bc1761-e8f6-446c-96f3-eb1b8f92628b/o sd-block-9f7fd40d-0698-40b9-8718-62942b03e263 there? Or should ceph-2 be the name of the symlink? I recommend to hire a professional to help you out, just to be on the safe > side. I've got a Ceph expert in our hackspace, but I'm not sure whether he can help me.

2 1