On Wed, Jul 09, 2008 at 10:52:54AM +1000, Dave Chinner wrote: > If you walk enough inodes while the filesystem is frozen, it > theoretically could happen. Typically a filesystem is only for a > few seconds at a time so in the real world this has never, ever been > a problem. I had argued for the timeout (and so it's mostly my fault that Takashi-San included it as a feature) mainly because I was (and still amm) deeply paranoid about the competence of the application programers who might use this feature. I could see them screwing up leaving it locked forever --- perhaps when their program core dumps or when the user types ^C and they forgot to install a signal handler, leaving the filesystem frozen forever. In the meantime, user applications that try to create files on that filesystem, or write to files already opened when the filesystem are frozen will accumulate dirty pages in the page cache, until the system finally falls over. Think about some of the evil perpetrated by hal and the userspace suspend-resume scripts (and how much complexity with random XML fragments getting parsed by various dbus plugins), and tell me with a straight face that you would trust these modern-day desktop application writers with this interface. Because they *will* find some interesting way to (ab)use it..... Also, I didn't think the extra code complexity to implements timeouts was *that* bad --- it seemed fairly small for the functionality. Best regards, - Ted -- 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
