Custom Query (1145 matches)


Show under each result:

Results (88 - 90 of 1145)

Ticket Resolution Summary Owner Reporter
#97 fixed Use unionfs instead of LVM snapshots geofft ghudson

Reported by ghudson, 14 years ago.


Right now we use LVM snapshots for copy-on-write functionality in two places: on the build server (linux-build-10) and for login chroots. This works pretty well, but it works at the storage layer, which is a somewhat heavyweight approach.

It is also possible to do this at the filesystem layer using unionfs. I do not know a lot about unionfs at this time, but tabbott reports that this approach performs better for large numbers of snapshots.

Unfortunately, schroot does not have support for unionfs at this time. There is a patch at:

tabbott has a port of it to schroot 1.2.1 if we want to pursue this.

#98 fixed Build server schroots get progressively slower ghudson

Reported by ghudson, 14 years ago.


Over time, creating and destroying LVM snapshots appears to get progressively slower. The slowdown is very gradual; on debuild the problem is likely to never become noticeable, but on linux-build-10 the presence of autodebathenify is causing a visible issue. Currently it takes about 105 seconds to create and tear down an schroot; it used to only take a few seconds.

Unfortunately, cleaning up leaked snapshots (there were about six as of yesterday) does not help, nor does rebooting. Backups of the LVM metadata were piling up in /etc/lvm/archive, but this was not the problem; nuking that directory and turning off archive snapshots does not help. Presumably there is some state inside the volume group which is piling up; I have not found any tools which will let me analyze the internal data structures at that level or perform any kind of garbage collection on them. "lvscan" is also very slow to complete.

It's conceivable that upgrading the kernel on the build server would help (the machine has not been kept up to date with Ubuntu). Barring that, the only temporary remediation I'm aware of is to blow away and recreate the volume group and re-make all the build chroots, a process which would be risky since I believe make-build-chroot does not work with current debootstrap (a separate issue).

A radical solution would be to use the unionfs schroot patch, as proposed in #97. That would eliminate the issue entirely, perhaps in exchange for other issues.

#99 fixed debathena-ntp-config should use transform-files andersk

Reported by andersk, 14 years ago.


debathena-ntp-config includes a modified version of ntp.conf from a particular ntp package. It should be rewritten to use transform-files (see so that it will work correctly on all distributions, incorporating modifications made to ntp.conf.

Note: See TracQuery for help on using queries.