On Mon, Oct 07, 2024 at 11:49:51AM GMT, ross.philip...@oracle.com wrote:
> On 10/3/24 8:40 PM, Michael Chang via Grub-devel wrote:
> > On Thu, Oct 03, 2024 at 10:30:15AM GMT, ross.philip...@oracle.com wrote:
> > > On 10/3/24 12:23 AM, Michael Chang via Grub-devel wrote:
> > > > Previously, the buff
On 10/3/24 8:40 PM, Michael Chang via Grub-devel wrote:
On Thu, Oct 03, 2024 at 10:30:15AM GMT, ross.philip...@oracle.com wrote:
On 10/3/24 12:23 AM, Michael Chang via Grub-devel wrote:
Previously, the buffer for LVM metadata parsing was set to twice the
size of the metadata area, which caused
On Thu, Oct 03, 2024 at 10:30:15AM GMT, ross.philip...@oracle.com wrote:
> On 10/3/24 12:23 AM, Michael Chang via Grub-devel wrote:
> > Previously, the buffer for LVM metadata parsing was set to twice the
> > size of the metadata area, which caused excessive memory use.
> >
> > This patch changes
On 10/3/24 12:23 AM, Michael Chang via Grub-devel wrote:
Previously, the buffer for LVM metadata parsing was set to twice the
size of the metadata area, which caused excessive memory use.
This patch changes the allocation to read the actual raw metadata blocks
directly from the metadata area. In
Previously, the buffer for LVM metadata parsing was set to twice the
size of the metadata area, which caused excessive memory use.
This patch changes the allocation to read the actual raw metadata blocks
directly from the metadata area. Instead of using twice the entire
metadata area size, we now
Previously, the buffer for LVM metadata parsing was set to twice the
size of the metadata area, which caused excessive memory use.
This patch changes the allocation to read the actual raw metadata blocks
directly from the metadata area. Instead of using twice the entire
metadata area size, we now
