storage-mon: Don't use random seeking when O_DIRECT is enabled

[kaneter]

Hi all,

I propose modifying to set random seeks only when the O_DIRECT flag is disabled.

I understand that the purpose of random seeks is to avoid false negatives that arise from reading from the page cache.
With the O_DIRECT flag enabled, it allows accessing the file system without going through the page cache.
This means that even without setting random seeks, it is possible to bypass the cache and read from the device directly.

[knet-jenkins]

Can one of the admins check and authorise this run please: https://ci.kronosnet.org/job/resource-agents/job/resource-agents-pipeline/job/PR-1968/1/input

[fabbione]

the reason to do random seek is also to probe different part of the disk and not just sector 0.

What problem are we trying to solve with this change?

[chrissie-c]

I'm not sure why we wouldn't want to do random checks around the disk in O_DIRECT mode; that seek was there mainly to run checks on different parts of the disk (not just the page cache), where random errors may be hiding.

Always checking sector 0 doesn't seem quite so useful, though I admit I'm no storage expert.

[wenningerk]

If using a random sector was just to not always read the same from cache not moving a potentially physical head around if not needed with O_DIRECT might make sense.
But loosing the possibility to scan a larger portion of the surface over time would be a pity as well.
Maybe adding an option to scan a fixed sector or within a range might keep both parties happy.
Depending on the use of the device in parallel 0 might not be the best guess anyway - given we're talking about performance reasons.

[kaneter]

the reason to do random seek is also to probe different part of the disk and not just sector 0.

Thank you for your guidance.
I was not aware that random seeks were intended for probing bad sectors.
This is because storage_mon reads the device only once per call.

Assuming a sector size of 512 bytes, and assuming no duplicates in the randomly chosen seek positions,
we can express the number of years required to inspect all sectors using the following equation:

time_required [years] = ((disk_size [bytes]) / 512 [bytes per sector]) / ((24 [hours] * 60 [minutes] * 60 [seconds]) / (interval_to_test [seconds])) / 365 [days]

For example, let's assume the following:

• disk_size = 16 [GiB] = 17,179,869,184 [bytes]
• interval_to_test = 30 [seconds]
  • (30 seconds is the default value for storage_mon.)

Then, the time_required is approximately 31 years and 10 months.

While there is a possibility of random seeks randomly finding bad sectors,
I believe that the bad sector probing performed by storage_mon is too slow.

However, if you expect storage_mon to find bad sectors, I think it would be best to retain these random seeks.
I personally do not have high expectations, so I thought it would be better to simplify the implementation.

Maybe adding an option to scan a fixed sector or within a range might keep both parties happy.

I agree. This idea respects both sides of the argument.
If we were to add an option, I think it would be best to keep random seeks enabled by default, so as not to change the existing behavior.

[wenningerk]

Guess you have to find some kind of a trade-off between a full surface-check and something that has so little impact that it can be done during operation.
I'm not an expert in this field but when we're thinking of a classical rotating disk we could at least assume that a sector from each of the surfaces would be checked within a reasonable time as to see if all of the heads can read properly. Same for sectors from inner tracks and sectors from outer tracks to see if the heads are able to move freely.
For shingled disks there would as well be quite some chance that you would hit a sector within these packs that are erased together (don't know the correct term here - in case of an SSD it would be an erase-block) regularly.