> It is definitely time - and critical (IMO) to correct these bugs.
> Having additional placement information specified on disk is nice and
> can often be very helpful.
Yeah, definitely. It requires a V3 COW, which is why I had been putting it
off. This is something I want to fix before I make a 2.4.20 release.
> While my experiments didn't show any appreciable speed up if data were
> aligned to sector size or page size, I still feel that any new COW
> format header should allow for an embedded and explicit offset to
> specify the start of data section.
When we have ubd mmap, then data will have to be page aligned.
> I also think a method for storing misc. (and non critical)
> information between the COW header and start of data should also be
> And while I'm thinking about it, I would like to propose an alternate,
> optional format for the COW sector bitmap: Rather than a bit map, an
> index array that indicates the offset into the COW file for each
> "sector" in use. As the COW file gets written to with new data, that
> data gets tacked onto the end of the file and the index array
> element(s) responsible for that data gets updated. I understand the
> overhead would be larger (1 megabyte per gigabyte of backing file),
> and may be slower to access, but the intent would be to allow the
> creation of large COW files that can exist on media such as CD-Roms,
> DOS filesystems, and other non-sparse devices.
Yeah, that sounds reasonable. For now, I would just add a format field to
the V3 header, with the current arrangement being format 0, and then we can
add this in a backward-compatible way later.
Are there any other proposals for changes that should go into the V3 COW