On Fri, Sep 10, 2010 at 12:22 PM, Avi Kivity <a...@redhat.com> wrote: > On 09/09/2010 08:43 PM, Anthony Liguori wrote: >>> >>> Hm, we do have a use case for qcow2-over-lvm. I can't say it's something >>> I like, but a point to consider. >> >> >> We specifically are not supporting that use-case in QED today. There's a >> good reason for it. For cluster allocation, we achieve good performance >> because for L2 cluster updates, we can avoid synchronous metadata updates >> (except for L1 updates). >> > > As I've mentioned several times, if you preallocate, then you amortize that > cost of keeping track of the physical image size. > >> We achieve synchronous metadata updates by leveraging the underlying >> filesystem's metadata. The underlying filesystems are much smarter about >> their metadata updates. They'll keep a journal to delay synchronous updates >> and other fancy things. > > They only guarantee that the filesystem is consistent. A write() that > extends a file may be reordered with the L2 write() that references the new > cluster. Requiring fsck on unclean shutdown is very backwards for a 2010 > format.
I'm interested in understanding how preallocation will work in a way that does not introduce extra flushes in the common case or require fsck. It seems to me that you can either preallocate and then rely on an fsck on startup to figure out which clusters are now really in use, or you can keep an exact max_cluster but this requires an extra write operation for each allocating write (and perhaps a flush?). Can you go into more detail in how preallocation should work? > >> >> If we tried to represent the disk size in the header, we would have to do >> an fsync() on every cluster allocation. > > On every N cluster allocations. > >> >> I can only imagine the use case for qcow2-over-lvm is performance. But >> the performance of QED on a file system is so much better than qcow2 that >> you can safely just use a file system and avoid the complexity of qcow2 over >> lvm. >> > > qcow2 over lvm is typically used on clusters. > > -- > I have a truly marvellous patch that fixes the bug which this > signature is too narrow to contain. > >
