Re: [PATCH v2 3/4] qcow2: Avoid feature name extension on small cluster size

2020-03-25 Thread Eric Blake
On 3/25/20 8:52 AM, Max Reitz wrote: If we want to write it like that, which size limit do you propose?  Or asked differently, how much space should we reserve for other extension headers + backing file name? Well, that was the “2k/3k/...” list. :) The backing file name is limited to 1k, so I

Re: [PATCH v2 3/4] qcow2: Avoid feature name extension on small cluster size

2020-03-25 Thread Max Reitz
On 25.03.20 14:18, Eric Blake wrote: > On 3/25/20 7:42 AM, Max Reitz wrote: >> On 24.03.20 18:42, Eric Blake wrote: >>> As the feature name table can be quite large (over 9k if all 64 bits >>> of all three feature fields have names; a mere 8 features leaves only >>> 8 bytes for a backing file name

Re: [PATCH v2 3/4] qcow2: Avoid feature name extension on small cluster size

2020-03-25 Thread Eric Blake
On 3/25/20 7:42 AM, Max Reitz wrote: On 24.03.20 18:42, Eric Blake wrote: As the feature name table can be quite large (over 9k if all 64 bits of all three feature fields have names; a mere 8 features leaves only 8 bytes for a backing file name in a 512-byte cluster), it is unwise to emit this o

Re: [PATCH v2 3/4] qcow2: Avoid feature name extension on small cluster size

2020-03-25 Thread Max Reitz
On 24.03.20 18:42, Eric Blake wrote: > As the feature name table can be quite large (over 9k if all 64 bits > of all three feature fields have names; a mere 8 features leaves only > 8 bytes for a backing file name in a 512-byte cluster), it is unwise > to emit this optional header in images with sm

[PATCH v2 3/4] qcow2: Avoid feature name extension on small cluster size

2020-03-24 Thread Eric Blake
As the feature name table can be quite large (over 9k if all 64 bits of all three feature fields have names; a mere 8 features leaves only 8 bytes for a backing file name in a 512-byte cluster), it is unwise to emit this optional header in images with small cluster sizes. Update iotest 036 to skip