On Monday 01 March 2004 8:36 am, Christophe Saout wrote: > Hi, > > > Revision 19: > > dm_suspend(): Don't unlock the fs if a race with another suspend is > > detected. > > 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. -- Kevin Corry kevcorry@xxxxxxxxxx http://evms.sourceforge.net/
