On Thu, May 10, 2007 at 02:44:48AM -0400, Theodore Tso wrote: > put it. The device names of USB storage devices end up getting > reused, so in practice what is in blkid.tab is merely the last storage > device that was plugged in, not every single one going back forever. My point with the USB example was that it keeps their labels around in a world-readable cache infinitely (or until a device with the same name gets mounted again). Its probably not a security issue in most cases, but its clutter which one doesn't expect to stick around. > One easy way of solving this problem is when we're parsing the file, > try to stat the device file, and if it doesn't exist, to skip parsing > the line together. This would prevent blkid.tab from growing without > bound given your workload. This idea of doing garbage collection every time blkid.tab is read destroys the cache if, for example, you mount /usr or /var before other block devices have been brought up. AoE and nbd come to mind as a potentially large number of devices that might not exist until later in the boot process. > The whole point of blkid.tab file was so that having searched all of > the devices to find the particular filesystem with a specified volume > label or UUID, that all of the information that was gathered doesn't > have to be searched a next time you need to do a mount-by-uuid or > mount-by-label. And if you have a large number of disks that you > might have to potentially spin up, you definitely want to keep this > cache across boots, which is why we store it in /etc/blkid.tab. Ok, but why do we bother caching the filesystem type? The desire to optimize the scanning for UUIDs or labels is indeed a real problem, but caching the filesystem type has the potential for introducing bugs and doesn't seem to have any real payoff. I for one have been bitten by the ext2 to ext3 upgrade bug more than once. There should be a better way of maintaining a UUID and label cache other than having mount keep an XML cache in /etc (which seems to violate the Linux filesystem hierarchy standard). Certainly having it enabled by default when there is no desire to mount by UUID or label is wasteful and probably the most common case. > So it sounds like the short-term fix is to simply add a test so that > if the device isn't present, we should just ignore the entry when we > read it into memory. The longer-term fix is use a more sophisticated > in-core representation which doesn't have a linear search time, and so > that algorithms to detect multiple lines referring to the same device > don't take O(n**2). We should also fix mount to avoid having it > unconditionally read in the blkid.tab file. The assumption was the > overhead for doing so should not be measurable. The first and safest step would seem to be removing the use of blkid.tab from mount except when trying to mount by UUID or volume label to prevent the performance issue when the cache is large. I think garbage collection is more complex to do safely and the whole approach might some re-thinking. Shapor - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
