On Mon, 2007-09-03 at 15:33 -0500, Douglas McClendon wrote:
Mark McLoughlin wrote:
>
> The main suggestion I'd have is that if the osmin.size was dropped[1],
Actually in my first iteration of the patch, I was using dumpe2fs, but
my parsing of it with awk and grep looked pretty ugly.
Something like this is nice and simple:
import commands
def parseField(output, field):
for line in output.split("\n"):
if line.startswith(field + ":"):
return line[len(field) + 1:].strip()
raise KeyError("Failed to find field '%s' in output" % field)
(status, output) = commands.getstatusoutput("/sbin/dumpe2fs -h /dev/root")
print parseField(output, "Block count")
> and if we could reduce the size of the COW area of the snapshot
to its
> minimal (i.e. look at how much is used and truncate it at that point),
This is pretty easy. In the intervening time, I am now confidently
aware that I can use dmsetup status on the snapshotted device to
determine how much of the file can be truncated.
Yep.
> then we can just include osmin.img directly and cut out a lot of
the
> tricks.
It needs to be compressed, which is why the truncation didn't really
matter. The reason it needs to be compressed, is because it can't live
in the squashfs, it has to live on the iso9660. And note, that it
compresses from 1.2M of actual data, to 7kb of actual data.
It can be truncated down to 1.2M, but it can still be compressed to
7kb? If so, the compression does sounds worthwhile.
Honestly I thought that using the exact same mechanism to propogate
osmin.img as was used to propogate os.img, was not a trick, but elegant.
What you have is mostly fine IMHO, it was the tarball I had a problem
with.
Cheers,
Mark.