Edward Shishkin wrote:

>On 3/3/08, John <geearf@free.fr> wrote:
>  
>
>> On Sun, 02 Mar 2008 13:17:12 +0300, Edward Shishkin <edward.shishkin@gmail.com> wrote:
>> > Hello.
>> >
>> > Yeah, indeed, I have reproduced it for reg40 (default plugin):
>> > tar process is in permanent "+D" state. After reboot all files
>> > were successfully deleted, although there is some leak of free
>> > disk space there.
>> >
>> > Ok, I'll take a look at this more carefully (I guess -ENOSPC
>> > error is handled incorrectly somewhere).
>> >
>> > If you have a problems with deleting files on reg40 partition,
>> > then please pack your metadata by
>> > debugfs.reiser4 -P /dev/xxx | gzip > meta.gz
>> > and let me download the file meta.gz
>>
>>My FS is currently no full and with no bug, so I hope these are the metadata you wanted.
>> If not I'll fill it again and send it to you again
>>
>> http://www.megaupload.com/?d=XVITV1CU
>>
>>    
>>
>
>Eventually I have not downloaded this:
>It said "No free slots available for your country" ;)
>
>Well, don't bother with this for a while:
>I have caught a mutex leak in cryptcompress plugin,
>(fixup is attached) this explains undeletable files in ccreg40.
>
>I'll try fo fix unix-file plugin a bit later.
>
>  
>

I have found some ancient bugs related to tail conversion.
In particular, it take place when application writes by chunks
< 20K in no-space-left-on-device situation (for example, tar,
which uses 10240 bytes chunks by default).
The bugs are:
. leak of per-inode exclusive access;
. leak of per-inode flag REISER4_PART_IN_CONV
All of them are responsible for reported deadlocks , and, perhaps
can lead to data corruptions.

The fixup is attached.

There still takes place a silent leak of free disk space, when
applications runs in no-space-left-on-device situation. This is also
related only to (default) unix-file plugin with (default) "smart"
formatting policy. Hope to address it soon..

Thanks for reports,
Edward.

>> (sorry I cannot send a file that big by e-mail)
>>
>>    
>>
>> > I don' t see such problems with ccreg40 (compression plugin).
>> > Please, let me know, if something goes wrong here..
>>
>>I just tried and had the same issue with a ccreg40 partition.
>> I could not remove all the files, and when I tried it just froze my shell.
>> After killing my shell I was able to reboot but not to umount the partition.
>> This is the debugfs output:
>>
>> http://www.megaupload.com/?d=CBEGIFDL
>>
>>
>> I also wanted to join an fsck output but I don't know how to do that.
>> Basically the results were in checking the semantic tree
>> FSCK: obj40_repair.c 223: obj40_stat_unix_check: Node (XYZ), item (a), [fgfdgf:fgfdggdf:fhgfhgf] (stat40): wrong bytes (ABCDE), fixed to (EFC).
>>
>> (obviously this is some sort of templated message, they were all like that...)
>>
>>
>> Thank you,
>>
>>
>> John
>>
>>
>>    
>>
>>------------------------------------------------------------------------
>>
>>---
>> linux-2.6.23-mm1/fs/reiser4/plugin/file/cryptcompress.c |    7 ++++---
>> 1 files changed, 4 insertions(+), 3 deletions(-)
>>
>>--- linux-2.6.23-mm1/fs/reiser4/plugin/file/cryptcompress.c.orig
>>+++ linux-2.6.23-mm1/fs/reiser4/plugin/file/cryptcompress.c
>>@@ -2721,7 +2721,8 @@
>> 		if (result)
>> 			goto out;
>> 		if (cont->state == PSCHED_ASSIGNED_NEW)
>>-			goto out_no_release;
>>+			/* done_lh was called in write_pschedule_hook */
>>+			goto out_no_longterm_lock;
>> 
>> 		result = prepare_logical_cluster(inode, pos, count, &clust,
>> 						 LC_APPOV);
>>@@ -2793,9 +2794,9 @@
>> 	} while (count);
>>  out:
>> 	done_lh(&hint->lh);
>>-	mutex_unlock(&info->checkin_mutex);
>> 	save_file_hint(file, hint);
>>- out_no_release:
>>+ out_no_longterm_lock:
>>+	mutex_unlock(&info->checkin_mutex);
>> 	kfree(hint);
>> 	put_cluster_handle(&clust);
>> 	assert("edward-195",
>>    
>>