Am Mo, den 01.03.2004 schrieb Kevin Corry um 15:55: > > I've got a question: Is it stupid to move the __unlock_fs from dm_resume > > to the end of dm_suspend? My webserver loves to deadlock when trying to > > snapshot the root volume without it... unfortunately I don't have direct > > access to the machine so I can't find out what exactly happens (it > > happened twice and I'm not to excited trying it too often because the > > watchdog reboots the machine hard after some minutes). > > > > Trying to avoid having a filesystem locked between two syscalls is > > probably not a too bad idea. If the filesystem is unlocked after > > BLOCK_IO is set the filesystem will be in a clean state and new requests > > will be deferred and submitted to the new table after resume anyway. > > This doesn't make a difference with the suspend syscall but seems to do > > with. > > I'd say it really depends on if the filesystems' unlockfs calls can block > waiting for I/O to complete. If they can, I'd think it would be invalid to > call unlockfs while the device is suspended. If we can ensure that the > filesystem will *never* block during that call, your suggestion might work. > Of course, I don't know enough about the various filesystems to answer that > question. Damn. You're right. This only works for reiserfs, ext3 locks up. This makes SUSPEND even more dangerous. I know it was dangerous but now it's nearly unusable. I have no idea why it locks up on the other machine. But I don't like the idea of getting the mount semaphore (lock_fs) in one syscall and releasing it in another. This feels wrong. And waiting for buffers when unlocking doesn't seem good either. Hmm.