lvm+loop-aes+reiserfs / iput deadlock fix

lvm+loop-aes+reiserfs / iput deadlock fix

[Newsmail]

Where does process hang this time? (press SysRQ-T, decode the output and 
send it to me) ---->
could you please tell me what is SysRQ-T? btw its a remote machine...
cheers,
greg

ps: well you say that its maybe a crypto-loop side problem, what I dont 
understand why it only came after 2.4.20-preX introduced, and it works 
absolutly without any problem on 2.4.19.

Re: lvm+loop-aes+reiserfs / iput deadlock fix

[Oleg Drokin]

Hello!

On Wed, Jan 29, 2003 at 11:34:10PM +0100, Newsmail wrote:
> Where does process hang this time? (press SysRQ-T, decode the output and 
> send it to me) ---->
> could you please tell me what is SysRQ-T? btw its a remote machine...

sysrq-T is combinatin of keys "Alt+PrtSc/SysRq+t" (three keys totally)
that should be pressed simultaneusly (in this order.).
You need to have sysrq enabled both in your kernel config and in 
sysctl (modern discros tend to disable it for some reason).

Well, if the box is remote, then may be you have serial console?
You need to send <Break> followed by T, then (over your serial line).

That will output list of currently running tasks and their stacks.

> ps: well you say that its maybe a crypto-loop side problem, what I dont 
> understand why it only came after 2.4.20-preX introduced, and it works 
> absolutly without any problem on 2.4.19.

Well, there were not only reiserfs changes in 2.4.20-pre series, you know.
You can even take content of fs/reiserfs/{*.c,Makefile} and
include/linux/reiserfs*.h from 2.4.19, put these into 2.4.20 kernel
sources at appropriate places, recompile the kernel and see what will happen.

I tried to write with reiserfs onto crypto-aes enabled loop device and
wrote 20G of data (with scp) without any problems. So it seems I cannot
reproduce that problem locally and I really need your help in debugging it.

Bye,
    Oleg

Re: lvm+loop-aes+reiserfs / iput deadlock fix

[Newsmail]

well, I'm using loop-aes'(loop-aes.sourceforge.net) AES128 on every HD, and 
on top of that I use LVM, and reiserfs on top of all this. Of course I know 
not only reiserfs changed in 2.4.20. First of all I'll set up a 2.4.20 at 
my home pc, and I'll reproduce the problem there. then I'll try to revert 
the 2.4.20-preX pending patches, and see what happens. if I find anything 
I'll send it to you. if all this doesnt work out I'll set you up a remote 
machine where the problem exists so you can investigate the problem there.
regards,
greg

lvm+loop-aes+reiserfs / iput deadlock fix

[Newsmail]

Hi Oleg, I tried out 
ftp://ftp.namesys.com/pub/reiserfs-for-2.4/2.4.20-pending/01-iput-deadlock-fix.diff 
patch on 2.4.20aa1 and this patch DOES improve the situation.
Before I used the patch when I made heavy copying of 10-50 meg files, after 
some time the copying process hung, and WASN'T killable. And also it left 
files that werent deletable, and also left the deleting process hung. and 
many times I wasnt even able to acces the folder where the strange file was 
located.
Now with the iput deadlock fix, the copying process does hang as well, BUT 
it is killable after, and the 'fucked up' file is deletable also.
Regards, and I'm awaiting some more updates,
best wishes,
greg

Re: lvm+loop-aes+reiserfs / iput deadlock fix

[Oleg Drokin]

Hello!

On Mon, Jan 27, 2003 at 12:11:37AM +0100, Newsmail wrote:

> ftp://ftp.namesys.com/pub/reiserfs-for-2.4/2.4.20-pending/01-iput-deadlock-fix.diff 
> patch on 2.4.20aa1 and this patch DOES improve the situation.

That's good... and bad.

> Before I used the patch when I made heavy copying of 10-50 meg files, after 
> some time the copying process hung, and WASN'T killable. And also it left 
> files that werent deletable, and also left the deleting process hung. and 
> many times I wasnt even able to acces the folder where the strange file was 
> located.
> Now with the iput deadlock fix, the copying process does hang as well, BUT 
> it is killable after, and the 'fucked up' file is deletable also.

That is clear sign of problems at new_inode() stage (something propagated from block level, I think).
And given that you do not have space shortage and any unusual kernel messages...
This is very strange.
Where does process hang this time? (press SysRQ-T, decode the output and send it to me)

Bye,
    Oleg