You are not logged in.

#1 2022-04-07 19:22:47

Ananas
Member
Registered: 2021-05-31
Posts: 5

Is it possible to disable LVM cache check on boot?

I recently experience an issue regarding waking up the machine from suspend. I suspect it's because of *glorious nvidia drivers*, but I have no way to check as the journal is not saved after such a crash.
The problem is, after each forced reboot (the system does not shut down correctly) I notice a huge hard drive activity from 'kworker/kcopyd'. I think it has something to do with LVM reloading the cache content after an unexpected shutdown.
I would prefer LVM to at least not hammer my drive until the suspend issue is resolved, so is there a way I can disable that check/reload of cache content by LVM (but leave the cache enabled) and reduce the long drive reads on boot?
Thank you in advance

Offline

#2 2022-04-12 15:44:58

JATothrim
Member
Registered: 2019-01-31
Posts: 15

Re: Is it possible to disable LVM cache check on boot?

If you have any lvm-cached volumes a hard crash can mark the cache volume "dirty".
If the system ends up in this state the kernel/device-mapper is now forced to flush the data out from the cache-volume to the origin volume.
Yours sounds like it is already flushing so the cache itself is useless until the kernel completes the work.

Check the device-mapper status of the volume with:

$ lvs -o+kernel_cache_settings,cache_settings,chunksize vg/cachevol
$ dmsetup status /dev/mapper/cachedvol

If root filesystem is not on that volume and you really want to pause this process simply deactivate the cached volume:

$ lvchange -an vg/cachedvol

After the cache flush is complete (this may take from minutes to hours)
I suggest you to detach/de-couple and re-create the cachevolume.
The recreation is because there exists two lvm-cache formats and the new format is more stable.
Try keep as many default options as possible: E.g.  the --chunksize can't be bigger than 1 megabyte.

To speedup the flushing try increase the migration threshold:

$ lvchange --cachesettings 'migration_threshold=2097152' cachedvol

And lastly, if the machine is prone to crashing I suggest you not to use lvm-cache.


If it ain't broken yet, some time passes and I'm doomed to learn its secrets.
Now it is half broken but twice as fast than before.

Offline

#3 2022-04-20 21:59:33

Ananas
Member
Registered: 2021-05-31
Posts: 5

Re: Is it possible to disable LVM cache check on boot?

Thank you for your response.

I've noticed the activity seems to be just reading from the hard drive, no writes, haven't checked the ssd activity though (the cache location).
So at this point I'm wondering what exactly does the flush process do? Is the huge read activity caused by lvm filling the cache with previous data by loading it from the volume again?
If so, would it be possible to let the cache refill *naturally* so to speak over time instead?

I didn't quite get the format part. It applies only if I've created the cache on some older version of lvm, right?

Offline

#4 2022-04-24 14:33:47

JATothrim
Member
Registered: 2019-01-31
Posts: 15

Re: Is it possible to disable LVM cache check on boot?

Ananas wrote:

Is the huge read activity caused by lvm filling the cache with previous data by loading it from the volume again?

If you are unsure if the kernel is itself initiating the I/O work then run:

$ iotop -a

Based what you have said I'd just let the lvm-cache do it's job:

lvm-cache will copy/move data when accessing the volume, even if you are only doing reads.
Once the frequently accessed data is cached this copy/move activity will diminish greatly.

Ananas wrote:

I didn't quite get the format part.

I have read bunch of other forums posts from Redhat etc. and I became to conclusion that
deviation from the default settings is bad for performance and stability of the cache.
Re-creating the cache-pool would ensure these conditions are met.
If the cache-pool is faily new, you don't need to worry about this.


If it ain't broken yet, some time passes and I'm doomed to learn its secrets.
Now it is half broken but twice as fast than before.

Offline

Board footer

Powered by FluxBB