Re: Do any of you have a policy on rebuilding indexes?

Hello Larry,

Am 01.04.2023 um 20:48 schrieb Larry DrFranken Bolhuis <midrange@xxxxxxxxxxxx>:

What if your data is on a SAN? Especially a modern one with RAID 6 protected storage, distributed hot spare, and 3 to 1 built in compression, on the NVMe modules. Where is your data now?

On disk(s). Still.

In this instance not only is Single Level Storage distributing your data across what it THINKS is a set of disks, but the SAN is emulating ('faking'?) those disks, and itself also spreading data across the NVMe modules.

Yes. But to me, that is largely irrelevant for storage management, considering fragmentation. The *results* of fragmentation might be practically nullified by using zero latency storage (NVMe), RAM cache in the storage subsystem, and very fast processing of individual block requests (instead of requesting a contiguous range of blocks — we're in the end still talking SCSI).

The system itself is theoretically relieved from "looking after" individual (rotating) disks. Less code involved (theoretica lly), responsibility to get the maximum performance yield is shifted towards the "storage itself". Not sure if this theoretical reduction in code path complexity has been implemented in practice within SLIC.

Fragmentation will still happen, though.

Not as common as it was a few years ago but software like EasyTier would further spread things around onto various velocity of storage devices depending on how often the data was accessed.

Ah, HSM. OS/400 had such a function once included.

Personally, in such an environment I wouldn't even consider a reload of my data to gain performance.

I fully agree. This is modern times with less tolerance about (even planned) downtime, much much more data being accumulated and an abundance of very fast and comparably cheap hardware resources. It's probably uneconomic to squeeze out maximum performance though such drastic and time consuming measures like reloading the complete system, on a very modern system as you've described.

:wq! PoC