Custom Query (1145 matches)
Results (61 - 63 of 1145)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #95 | fixed | Names for session types need improvement. | wdc | |
| Description |
I got tripped up by the names of the different sessions, and whether the change I was making was a permanent or a transient one. This issue tracks refinement of that session choice display until we've got something that Athena Cluster users will find usable. |
|||
| #96 | fixed | Automounter should support manually-specified lockers | geofft | |
| Description |
Maintainers of replicated lockers often want to attach the read-write copy of a locker in /mit to test it, before releasing the volume. We should add an interface for pyhesiodfs to support this. Detaching, deleting and re-symlinking the locker is what people will try to do... can we support root symlinking on top of an existing locker as changing where it points? |
|||
| #98 | fixed | Build server schroots get progressively slower | ghudson | |
| Description |
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. |
|||
