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
