Hi,
On 26/03/2021 13:46, Alexander Ahring Oder Aring wrote:
Hi,
On Fri, Mar 26, 2021 at 6:41 AM Andrew Price <anpr...@redhat.com> wrote:
On 25/03/2021 17:58, Alexander Aring wrote:
This patch removes a note that the barrier option is automatically turned
off if the underlaying device doesn't support I/O barriers. So far I
understand it's default on, means "barriers" option is applied which
should not make any problems if the underlaying device supports something
or not. There is by the kernel or gfs2-utils no automatically detection
going on which changes this mount option.
Hm, should there be automatic detection? Has there ever been? I'd like
to get to the bottom of why this language is here before removing it.
no idea if there was ever an auto detection or there exists currently
one. I didn't find any auto detection during my research. The related
part came in by: 06b5fb87 ("gfs2: man page updates"). My understanding
is that this option is default "barrier" and you should do "nobarrier"
in cases when you know what you are doing. I even don't know if such
automatic detection is possible, the man-page says "(e.g. its on a
UPS, or it doesn't have a write cache)" in regards to block devices. I
think there is no way in the kernel/user space to check if the block
device is behind a UPS. Maybe there exists some in user space over
hdparm but then things need to be right connected? Regarding cache
handling, you need to know a lot about the used architecture.
I am not sure here as well. I was reading about such automatic
detection and wanted to see how it's done with the result: there is no
auto detection (in gfs2(kernel)/gfs2-utils software)?
- Alex
Bare in mind that the naming of the barrier mount option is historic and
that it is now implemented using flush commands rather than barriers. I
don't think there is any automated way to discover if it is safe to run
without flushes,
Steve.
