[dm-devel] 2.6.3-udm5

[Christophe Saout]

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.