On Fri, Aug 5, 2022 at 9:30 AM Kazunori INOUE <kazunori_in...@newson.co.jp> wrote: > > On Tue, Aug 2, 2022 at 11:09 PM Ken Gaillot <kgail...@redhat.com> wrote: > > > > On Tue, 2022-08-02 at 19:13 +0900, 井上和徳 wrote: > > > Hi, > > > > > > Since O_DIRECT is not specified in open() [1], it reads the buffer > > > cache and > > > may result in a false negative. I fear that this possibility > > > increases > > > in environments with large buffer cache and running disk-reading > > > applications > > > such as database. > > > > > > So, I think it's better to specify O_RDONLY|O_DIRECT, but what about > > > it? > > > (in this case, lseek() processing is unnecessary.) > > > > > > # I am ready to create a patch that works with O_DIRECT. Also, I > > > wouldn't mind > > > # a "change to add a new mode of inspection with O_DIRECT > > > # (add a option to storage_mon) while keeping the current inspection > > > process". > > > > > > [1] > > > https://github.com/ClusterLabs/resource-agents/blob/main/tools/storage_mon.c#L47-L90 > > > > > > Best Regards, > > > Kazunori INOUE > > > > I agree, it makes sense to use O_DIRECT when available. I don't think > > an option is necessary. > > > > However, O_DIRECT is not available on all OSes, so the configure script > > should detect support. Also, it is not supported by all filesystems, so > > if the open fails, we should retry without O_DIRECT. > > -- > > Ken Gaillot <kgail...@redhat.com> > > > > Thank you, everyone. > I will create a patch using O_DIRECT. > (I'm also interested in AIO, but I don't have a track record of using it,
Not saying you have to use it nor that it is a perfect reference implementation but it is proven to work to a certain extent - and well - I know it ;-) https://github.com/ClusterLabs/sbd/blob/main/src/sbd-md.c Not sure as well if it is of much benefit for a usage pattern without a persistent daemon. And it is Linux proprietary. Unfortunately posix aio implementation seems not to be using the kernel-api (yet). What you could adopt from the sbd-code might be getting the block-size from the device instead of assuming 512 bytes (what iirc the current code does). Klaus > so I'm going to see it off this time.) > > Kazunori INOUE > > > > _______________________________________________ > Manage your subscription: > https://lists.clusterlabs.org/mailman/listinfo/users > > ClusterLabs home: https://www.clusterlabs.org/ _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
