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
 |