bcl
commented
1 year ago Do you mean the BLKFLSBUF ioctl call from parted?
I've dropped the readonly patch idea because it ends up you still have to open it in write mode to do the fsync successfully. And we need to do that to ensure we're reading the correct partition data so there's no way to avoid opening it in write mode, even when only printing the current state.
As far as BLKFLSBUF is concerned it should only be called on the main device and on unmounted partitions. If it is getting called on a mounted partition that is a bug.
The best place to discuss parted issues is on the mailing list at https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/parted-devel
This repo is a (sometimes out of date) mirror that I use to share patches more easily and isn't for 'official' parted support.
rogerheflin
parted -l seems to cause bdev_invalidate to get called droping the block cache and causing perf issues on spinning disks under certain conditions. Since parted -l is called to only list partition info out (and uses by sosreport and similar tools) can something be done to prevent the cache drop?
This seems to effect ext2/3/4 that relies on the block device cache to cache directory entries. On spinning disks with large enough directories the cache drop causes a 60+ second pause to reload the cache. The fs needs to have has large directory entries, or simply a lot of directory entries in the cache (Yes I know best to avoid big directories) to cause this performance impact.
The bdev_invalidate coming from partprobe and parted -l was confirmed with a ksplice patch used while debugging what was causing the cache to get dropped. I am less worried about the partprobe case since those are easier calls to avoid, but even in the partprobe case it might be nice if the cache was not dropped.
fdisk -l does not seem to cause a call to bdev_invalidate.
I see a --readonly patch, it might work if -l defaults to --readonly and does not do a cache flush/drop.