On Tue, Jul 08, 2008 at 09:09:22PM -0400, Theodore Tso wrote: > 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. Just as an extra point of reference, VxFS supports a freeze/thaw by ioctl very similar to this including a timeout in seconds. This means someone else thought it was a useful feature. http://sfdoccentral.symantec.com/sf/5.0/linux/manpages/vxfs/vxfsio_7.html Brad Boyer flar@xxxxxxxxxxxxx -- 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
