Using "profile rbd-read-only" with krbd wouldn't work unless you are on kernel 5.5 or later. Prior to 5.5, "rbd map" code in the kernel did some things that are incompatible with "profile rbd-read-only", such as establishing a watch on the image header and more. This was overlooked because it is sufficient to map with "-o ro" to get a read-only block device. "profile rbd-read-only" just provides an extra assurance on the OSD side and helps with user management. Thanks, Ilya On Mon, May 4, 2020 at 7:56 PM Paul Emmerich <paul.emmerich@xxxxxxxx> wrote: > > Yeah, file systems rarely really do a read-only mount without providing > some very obscure options, no idea about xfs specifically. > > Suggestion: use a keyring with profile rbd-read-only to ensure that it > definitely can't write when mapping the rbd. xfs might just do the right > thing automatically when encountering a read-only block device > > > Paul > > -- > Paul Emmerich > > Looking for help with your Ceph cluster? Contact us at https://croit.io > > croit GmbH > Freseniusstr. 31h > 81247 München > www.croit.io > Tel: +49 89 1896585 90 > > > On Mon, May 4, 2020 at 7:05 PM Void Star Nill <void.star.nill@xxxxxxxxx> > wrote: > > > Thanks Janne. I actually meant that the RW mount is unmounted already - > > sorry about the confusion. > > > > - Shridhar > > > > On Mon, 4 May 2020 at 00:35, Janne Johansson <icepic.dz@xxxxxxxxx> wrote: > > > > > Den mån 4 maj 2020 kl 05:14 skrev Void Star Nill < > > void.star.nill@xxxxxxxxx > > > >: > > > > > >> One of the use cases (e.g. machine learning workloads) for RBD volumes > > in > > >> our production environment is that, users could mount an RBD volume in > > RW > > >> mode in a container, write some data to it and later use the same volume > > >> in > > >> RO mode into a number of containers in parallel to consume the data. > > >> > > >> I am trying to test this scenario with different file systems (ext3/4 > > and > > >> xfs). I have an automated test code that creates a volume, maps it to a > > >> node, mounts in RW mode and write some data into it. Later the same > > volume > > >> is mounted in RO mode in a number of other nodes and a process reads > > from > > >> the file. > > >> > > > > > > Is the RW unmounted or not? You write "stopped writing" but that doesn't > > > clearly > > > indicate if you make it impossible or just "I ask it to not make much > > IO". > > > Given that many filesystems are doing very lazy writes, caches a lot and > > > so on, > > > it would be very important to make sure 1) ALL writes are done, which is > > > easiest with > > > umount I think and 2) that mounting clients knows can't write to it at > > > all, or otherwise > > > as someone said, it might still be updating some metainfo like the > > > journals or > > > "last mounted on /X" or whatever magic fs's store even while not altering > > > the files > > > inside the fs. > > > > > > It's kind of hard to tell filesystems that are accustomed to being in > > > charge of all > > > mounted instances to sit in the back seat and not be allowed to control > > > stuff. > > > > > > -- > > > May the most significant bit of your life be positive. > > > > > _______________________________________________ > > ceph-users mailing list -- ceph-users@xxxxxxx > > To unsubscribe send an email to ceph-users-leave@xxxxxxx > > > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx > To unsubscribe send an email to ceph-users-leave@xxxxxxx _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx