mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[David Dabbs]

I was running mongo when the following occurred:

 cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error
 cp: cannot stat `/mnt/testfs/testdir0-0-0/f93': Input/output error
 cp: cannot stat `/mnt/testfs/testdir0-0-0/f94': Input/output error
 cp: cannot stat `/mnt/testfs/testdir0-0-0/f95': Input/output error
 cp: cannot stat `/mnt/testfs/testdir0-0-0/f97': Input/output error


I found the following in the log:

Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
(fs/reiser4/search.c:1033)[vs-3533]:
Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
(fs/reiser4/search.c:1033)[vs-3533]:
Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
(fs/reiser4/search.c:1033)[vs-3533]:
Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
(fs/reiser4/search.c:1033)[vs-3533]:
Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
(fs/reiser4/search.c:1033)[vs-3533]:
Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
(fs/reiser4/search.c:1033)[vs-3533]:
Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
(fs/reiser4/search.c:1033)[vs-3533]:
Aug  3 21:59:59 linux kernel: WARNING: Keys are inconsistent. Fsck?
Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: key_warning
(fs/reiser4/plugin/object.c:97)[nikita-717]:
Aug  3 21:59:59 linux kernel: WARNING: Error for inode 661097 (-5)
Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: write_sd_by_inode_common
(fs/reiser4/plugin/object.c:480)[nikita-2221]:
Aug  3 21:59:59 linux kernel: WARNING: Failed to save sd for 661097: -5
Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: create_child_common
(fs/reiser4/plugin/dir/dir.c:499)[nikita-2219]:
Aug  3 21:59:59 linux kernel: WARNING: Failed to create sd for 661097
Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
(fs/reiser4/search.c:1033)[vs-3533]:
Aug  3 21:59:59 linux kernel: WARNING: Keys are inconsistent. Fsck?
Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: key_warning 


I had been switching back and forth between computers via a kvm switch. I
attempted to reproduce the error by rerunning the benchmark and figddling
with the switch, but was not able to see the same behavior.

Running with latest auto-snapshot and reiser4fsprogs.

David

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[Hans Reiser]

David Dabbs wrote:

>I was running mongo when the following occurred:
>
> cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error
> cp: cannot stat `/mnt/testfs/testdir0-0-0/f93': Input/output error
> cp: cannot stat `/mnt/testfs/testdir0-0-0/f94': Input/output error
> cp: cannot stat `/mnt/testfs/testdir0-0-0/f95': Input/output error
> cp: cannot stat `/mnt/testfs/testdir0-0-0/f97': Input/output error
>
>
>I found the following in the log:
>
>Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>(fs/reiser4/search.c:1033)[vs-3533]:
>Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>(fs/reiser4/search.c:1033)[vs-3533]:
>Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>(fs/reiser4/search.c:1033)[vs-3533]:
>Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>(fs/reiser4/search.c:1033)[vs-3533]:
>Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>(fs/reiser4/search.c:1033)[vs-3533]:
>Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>(fs/reiser4/search.c:1033)[vs-3533]:
>Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>(fs/reiser4/search.c:1033)[vs-3533]:
>Aug  3 21:59:59 linux kernel: WARNING: Keys are inconsistent. Fsck?
>Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: key_warning
>(fs/reiser4/plugin/object.c:97)[nikita-717]:
>Aug  3 21:59:59 linux kernel: WARNING: Error for inode 661097 (-5)
>Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: write_sd_by_inode_common
>(fs/reiser4/plugin/object.c:480)[nikita-2221]:
>Aug  3 21:59:59 linux kernel: WARNING: Failed to save sd for 661097: -5
>Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: create_child_common
>(fs/reiser4/plugin/dir/dir.c:499)[nikita-2219]:
>Aug  3 21:59:59 linux kernel: WARNING: Failed to create sd for 661097
>Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>(fs/reiser4/search.c:1033)[vs-3533]:
>Aug  3 21:59:59 linux kernel: WARNING: Keys are inconsistent. Fsck?
>Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: key_warning 
>
>
>I had been switching back and forth between computers via a kvm switch. I
>attempted to reproduce the error by rerunning the benchmark and figddling
>with the switch, but was not able to see the same behavior.
>
>Running with latest auto-snapshot and reiser4fsprogs.
>
>David
>
>
>
>
>  
>
Well, it seems you found a bug just as we were about to ship.   Sigh.

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[Vladimir V. Saveliev]

Hello

Hans Reiser wrote:
> David Dabbs wrote:
> 
>> I was running mongo when the following occurred:
>>
>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error
>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f93': Input/output error
>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f94': Input/output error
>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f95': Input/output error
>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f97': Input/output error
>>
>>
>> I found the following in the log:
>>
>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>> (fs/reiser4/search.c:1033)[vs-3533]:
>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>> (fs/reiser4/search.c:1033)[vs-3533]:
>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>> (fs/reiser4/search.c:1033)[vs-3533]:
>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>> (fs/reiser4/search.c:1033)[vs-3533]:
>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>> (fs/reiser4/search.c:1033)[vs-3533]:
>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>> (fs/reiser4/search.c:1033)[vs-3533]:
>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>> (fs/reiser4/search.c:1033)[vs-3533]:
>> Aug  3 21:59:59 linux kernel: WARNING: Keys are inconsistent. Fsck?
>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: key_warning
>> (fs/reiser4/plugin/object.c:97)[nikita-717]:
>> Aug  3 21:59:59 linux kernel: WARNING: Error for inode 661097 (-5)
>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: 
>> write_sd_by_inode_common
>> (fs/reiser4/plugin/object.c:480)[nikita-2221]:
>> Aug  3 21:59:59 linux kernel: WARNING: Failed to save sd for 661097: -5
>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: create_child_common
>> (fs/reiser4/plugin/dir/dir.c:499)[nikita-2219]:
>> Aug  3 21:59:59 linux kernel: WARNING: Failed to create sd for 661097
>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>> (fs/reiser4/search.c:1033)[vs-3533]:
>> Aug  3 21:59:59 linux kernel: WARNING: Keys are inconsistent. Fsck?
>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: key_warning
>>
>> I had been switching back and forth between computers via a kvm switch. I
>> attempted to reproduce the error by rerunning the benchmark and figddling
>> with the switch, but was not able to see the same behavior.
>>
>> Running with latest auto-snapshot and reiser4fsprogs.
>>
>> David
>>
>>
>>
>>
>>  
>>
> Well, it seems you found a bug just as we were about to ship.   Sigh.
> 
> 

Hans, should we solve this before sending reiser4 to Andrew?

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[Hans Reiser]

Vladimir V. Saveliev wrote:

> Hello
>
> Hans Reiser wrote:
>
>> David Dabbs wrote:
>>
>>> I was running mongo when the following occurred:
>>>
>>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error
>>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f93': Input/output error
>>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f94': Input/output error
>>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f95': Input/output error
>>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f97': Input/output error
>>>
>>>
>>> I found the following in the log:
>>>
>>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>> (fs/reiser4/search.c:1033)[vs-3533]:
>>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>> (fs/reiser4/search.c:1033)[vs-3533]:
>>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>> (fs/reiser4/search.c:1033)[vs-3533]:
>>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>> (fs/reiser4/search.c:1033)[vs-3533]:
>>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>> (fs/reiser4/search.c:1033)[vs-3533]:
>>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>> (fs/reiser4/search.c:1033)[vs-3533]:
>>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>> (fs/reiser4/search.c:1033)[vs-3533]:
>>> Aug  3 21:59:59 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: key_warning
>>> (fs/reiser4/plugin/object.c:97)[nikita-717]:
>>> Aug  3 21:59:59 linux kernel: WARNING: Error for inode 661097 (-5)
>>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: 
>>> write_sd_by_inode_common
>>> (fs/reiser4/plugin/object.c:480)[nikita-2221]:
>>> Aug  3 21:59:59 linux kernel: WARNING: Failed to save sd for 661097: -5
>>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: create_child_common
>>> (fs/reiser4/plugin/dir/dir.c:499)[nikita-2219]:
>>> Aug  3 21:59:59 linux kernel: WARNING: Failed to create sd for 661097
>>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>> (fs/reiser4/search.c:1033)[vs-3533]:
>>> Aug  3 21:59:59 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: key_warning
>>>
>>> I had been switching back and forth between computers via a kvm 
>>> switch. I
>>> attempted to reproduce the error by rerunning the benchmark and 
>>> figddling
>>> with the switch, but was not able to see the same behavior.
>>>
>>> Running with latest auto-snapshot and reiser4fsprogs.
>>>
>>> David
>>>
>>>
>>>
>>>
>>>  
>>>
>> Well, it seems you found a bug just as we were about to ship.   Sigh.
>>
>>
>
> Hans, should we solve this before sending reiser4 to Andrew?
>
>
>
>
>
If it is due to 4k stacks, then find a way to ensure that use of reiser4 
turns off 4k stacks before sending to Andrew.

Hans

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[mjt]

On Wed, Aug 04, 2004 at 12:51:26PM +0400, Vladimir V. Saveliev wrote:

>Hans, should we solve this before sending reiser4 to Andrew?

I ain't Hans, but why not? :)

I also got an idea on the latest reiser4progs; Why not just make the
format change optional, or comment out the code that makes the format
change, if there were other good fixes?

Tell us where we are going before something bad happens, I don't want
to back up a hundred gigabytes of stuff in vain, even if I was always
prepared for it. (I have backups of only the stuff that REALLY matters..)

-- 
mjt

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[Vladimir V. Saveliev]

Hans Reiser wrote:
> Vladimir V. Saveliev wrote:
> 
>> Hello
>>
>> Hans Reiser wrote:
>>
>>> David Dabbs wrote:
>>>
>>>> I was running mongo when the following occurred:
>>>>
>>>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error
>>>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f93': Input/output error
>>>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f94': Input/output error
>>>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f95': Input/output error
>>>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f97': Input/output error
>>>>
>>>>
>>>> I found the following in the log:
>>>>
>>>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>>> (fs/reiser4/search.c:1033)[vs-3533]:

[snip]

>>>> Aug  3 21:59:59 linux kernel: WARNING: Failed to create sd for 661097
>>>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>>> (fs/reiser4/search.c:1033)[vs-3533]:
>>>> Aug  3 21:59:59 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: key_warning
>>>>
>>>> I had been switching back and forth between computers via a kvm 
>>>> switch. I
>>>> attempted to reproduce the error by rerunning the benchmark and 
>>>> figddling
>>>> with the switch, but was not able to see the same behavior.
>>>>
>>>> Running with latest auto-snapshot and reiser4fsprogs.
>>>>
>>>> David
>>>>
>>>>
>>>>
>>>>
>>>>  
>>>>
>>> Well, it seems you found a bug just as we were about to ship.   Sigh.
>>>
>>>
>>
>> Hans, should we solve this before sending reiser4 to Andrew?
>>
>>
>>
>>
>>
> If it is due to 4k stacks,

No, I do not think it is.

  then find a way to ensure that use of reiser4
> turns off 4k stacks before sending to Andrew.
> 
reiser4 now refuses to compile if 4k stack is on.


> Hans
> 
> 

RE: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[David Dabbs]

This is different from the mount issue, which was fixed by the new code
drop. This was built with 8k stacks.

David


> -----Original Message-----
> From: Hans Reiser [mailto:reiser@namesys.com]
> Sent: Wednesday, August 04, 2004 3:59 AM
> To: Vladimir V. Saveliev
> Cc: David Dabbs; reiserfs-list@namesys.com
> Subject: Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92':
> Input/output error
> 
> Vladimir V. Saveliev wrote:
> 
> > Hello
> >
> > Hans Reiser wrote:
> >
> >> David Dabbs wrote:
> >>
> >>> I was running mongo when the following occurred:
> >>>
> >>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error
> >>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f93': Input/output error
> >>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f94': Input/output error
> >>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f95': Input/output error
> >>> cp: cannot stat `/mnt/testfs/testdir0-0-0/f97': Input/output error
> >>>
> >>>
> >>> I found the following in the log:
> >>>
> >>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
> >>> (fs/reiser4/search.c:1033)[vs-3533]:
> >>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
> >>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
> >>> (fs/reiser4/search.c:1033)[vs-3533]:
> >>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
> >>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
> >>> (fs/reiser4/search.c:1033)[vs-3533]:
> >>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
> >>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
> >>> (fs/reiser4/search.c:1033)[vs-3533]:
> >>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
> >>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
> >>> (fs/reiser4/search.c:1033)[vs-3533]:
> >>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
> >>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
> >>> (fs/reiser4/search.c:1033)[vs-3533]:
> >>> Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
> >>> Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
> >>> (fs/reiser4/search.c:1033)[vs-3533]:
> >>> Aug  3 21:59:59 linux kernel: WARNING: Keys are inconsistent. Fsck?
> >>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: key_warning
> >>> (fs/reiser4/plugin/object.c:97)[nikita-717]:
> >>> Aug  3 21:59:59 linux kernel: WARNING: Error for inode 661097 (-5)
> >>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]:
> >>> write_sd_by_inode_common
> >>> (fs/reiser4/plugin/object.c:480)[nikita-2221]:
> >>> Aug  3 21:59:59 linux kernel: WARNING: Failed to save sd for 661097: -
> 5
> >>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: create_child_common
> >>> (fs/reiser4/plugin/dir/dir.c:499)[nikita-2219]:
> >>> Aug  3 21:59:59 linux kernel: WARNING: Failed to create sd for 661097
> >>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
> >>> (fs/reiser4/search.c:1033)[vs-3533]:
> >>> Aug  3 21:59:59 linux kernel: WARNING: Keys are inconsistent. Fsck?
> >>> Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: key_warning
> >>>
> >>> I had been switching back and forth between computers via a kvm
> >>> switch. I
> >>> attempted to reproduce the error by rerunning the benchmark and
> >>> figddling
> >>> with the switch, but was not able to see the same behavior.
> >>>
> >>> Running with latest auto-snapshot and reiser4fsprogs.
> >>>
> >>> David
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >> Well, it seems you found a bug just as we were about to ship.   Sigh.
> >>
> >>
> >
> > Hans, should we solve this before sending reiser4 to Andrew?
> >
> >
> >
> >
> >
> If it is due to 4k stacks, then find a way to ensure that use of reiser4
> turns off 4k stacks before sending to Andrew.
> 
> Hans

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[Hans Reiser]

Please do whatever you can to reproduce this.  We are going to delay 
release by one day to see if it can be reproduced.  Vs thinks it might 
be a hardware problem, I am not so optimistic, what are your thoughts?

Hans

David Dabbs wrote:

>This is different from the mount issue, which was fixed by the new code
>drop. This was built with 8k stacks.
>
>David
>
>
>  
>
>>-----Original Message-----
>>From: Hans Reiser [mailto:reiser@namesys.com]
>>Sent: Wednesday, August 04, 2004 3:59 AM
>>To: Vladimir V. Saveliev
>>Cc: David Dabbs; reiserfs-list@namesys.com
>>Subject: Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92':
>>Input/output error
>>
>>Vladimir V. Saveliev wrote:
>>
>>    
>>
>>>Hello
>>>
>>>Hans Reiser wrote:
>>>
>>>      
>>>
>>>>David Dabbs wrote:
>>>>
>>>>        
>>>>
>>>>>I was running mongo when the following occurred:
>>>>>
>>>>>cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error
>>>>>cp: cannot stat `/mnt/testfs/testdir0-0-0/f93': Input/output error
>>>>>cp: cannot stat `/mnt/testfs/testdir0-0-0/f94': Input/output error
>>>>>cp: cannot stat `/mnt/testfs/testdir0-0-0/f95': Input/output error
>>>>>cp: cannot stat `/mnt/testfs/testdir0-0-0/f97': Input/output error
>>>>>
>>>>>
>>>>>I found the following in the log:
>>>>>
>>>>>Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>>>>(fs/reiser4/search.c:1033)[vs-3533]:
>>>>>Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>>>>Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>>>>(fs/reiser4/search.c:1033)[vs-3533]:
>>>>>Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>>>>Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>>>>(fs/reiser4/search.c:1033)[vs-3533]:
>>>>>Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>>>>Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>>>>(fs/reiser4/search.c:1033)[vs-3533]:
>>>>>Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>>>>Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>>>>(fs/reiser4/search.c:1033)[vs-3533]:
>>>>>Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>>>>Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>>>>(fs/reiser4/search.c:1033)[vs-3533]:
>>>>>Aug  3 21:59:58 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>>>>Aug  3 21:59:58 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>>>>(fs/reiser4/search.c:1033)[vs-3533]:
>>>>>Aug  3 21:59:59 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>>>>Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: key_warning
>>>>>(fs/reiser4/plugin/object.c:97)[nikita-717]:
>>>>>Aug  3 21:59:59 linux kernel: WARNING: Error for inode 661097 (-5)
>>>>>Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]:
>>>>>write_sd_by_inode_common
>>>>>(fs/reiser4/plugin/object.c:480)[nikita-2221]:
>>>>>Aug  3 21:59:59 linux kernel: WARNING: Failed to save sd for 661097: -
>>>>>          
>>>>>
>>5
>>    
>>
>>>>>Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: create_child_common
>>>>>(fs/reiser4/plugin/dir/dir.c:499)[nikita-2219]:
>>>>>Aug  3 21:59:59 linux kernel: WARNING: Failed to create sd for 661097
>>>>>Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: cbk_level_lookup
>>>>>(fs/reiser4/search.c:1033)[vs-3533]:
>>>>>Aug  3 21:59:59 linux kernel: WARNING: Keys are inconsistent. Fsck?
>>>>>Aug  3 21:59:59 linux kernel: reiser4[cp(10066)]: key_warning
>>>>>
>>>>>I had been switching back and forth between computers via a kvm
>>>>>switch. I
>>>>>attempted to reproduce the error by rerunning the benchmark and
>>>>>figddling
>>>>>with the switch, but was not able to see the same behavior.
>>>>>
>>>>>Running with latest auto-snapshot and reiser4fsprogs.
>>>>>
>>>>>David
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>Well, it seems you found a bug just as we were about to ship.   Sigh.
>>>>
>>>>
>>>>        
>>>>
>>>Hans, should we solve this before sending reiser4 to Andrew?
>>>
>>>
>>>
>>>
>>>
>>>      
>>>
>>If it is due to 4k stacks, then find a way to ensure that use of reiser4
>>turns off 4k stacks before sending to Andrew.
>>
>>Hans
>>    
>>
>
>
>
>  
>

RE: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[David Dabbs]

Something to add regarding the following errors from last night:

cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

As part of my mongo benchmarking, I have added two steps before all other
processing:

1. Create a large number of directories on the benchmark device. These are
taken from a list of actual directories on my machine and are created under
the mount point for the test device e.g. my /etc becomes /mnt/testfs/etc. 

2. Create a large number of files on the test device. This is done using a
modified version of one of the mongo_ programs. Each file is simply created
by open(O_CREAT) then closed immediately. I can't tell you how many files
are created right now because I'm in the middle of running an ext3
benchmark, but it is a large number of files, each zero length. No shipped
mongo sources were changed, save mongo.pl (to include the new phases) and an
added LOG statement so I can watch each iteration command execute.

I spend a long time last night retesting mongo runs with and without the
MKDIRS and MKFILES phases to see if they had contributed to the errors, but
could not find any relationship.

I hope this helps in some way.


David

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[Chris Mason]

On Wed, 2004-08-04 at 13:38, Hans Reiser wrote:
> Please do whatever you can to reproduce this.  We are going to delay 
> release by one day to see if it can be reproduced.  Vs thinks it might 
> be a hardware problem, I am not so optimistic, what are your thoughts?
> 

If it currently passes all of your internal tests, and the disk format
is fixed, I'd release it.  There are going to be bugs found, pretty much
everyone expects v4 to go through a churning period.

-chris

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[Hans Reiser]

David Dabbs wrote:

>Something to add regarding the following errors from last night:
>
>cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error
>
>As part of my mongo benchmarking, I have added two steps before all other
>processing:
>
>1. Create a large number of directories on the benchmark device. These are
>taken from a list of actual directories on my machine and are created under
>the mount point for the test device e.g. my /etc becomes /mnt/testfs/etc. 
>
>2. Create a large number of files on the test device. This is done using a
>modified version of one of the mongo_ programs. Each file is simply created
>by open(O_CREAT) then closed immediately. I can't tell you how many files
>are created right now because I'm in the middle of running an ext3
>benchmark, but it is a large number of files, each zero length. No shipped
>mongo sources were changed, save mongo.pl (to include the new phases) and an
>added LOG statement so I can watch each iteration command execute.
>
>I spend a long time last night retesting mongo runs with and without the
>MKDIRS and MKFILES phases to see if they had contributed to the errors, but
>could not find any relationship.
>
>I hope this helps in some way.
>
>
>David
>
>
>
>
>
>
>
>  
>
For us to reproduce, we need to have a script of some sort that exactly 
reproduces what you did.

It is especially significant to note such things as whether you might 
have run out of disk space, etc.

It makes a lot of sense that you did not run stock mongo, because elena 
runs that a lot and we likely would have hit the bug already if you had.

RE: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[David Dabbs]

> -----Original Message-----
> From: Hans Reiser [mailto:reiser@namesys.com]
> Sent: Wednesday, August 04, 2004 12:39 PM
> To: David Dabbs
> Cc: 'Vladimir V. Saveliev'; reiserfs-list@namesys.com
> Subject: Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92':
> Input/output error
> 
> Please do whatever you can to reproduce this.  We are going to delay
> release by one day to see if it can be reproduced.  Vs thinks it might
> be a hardware problem, I am not so optimistic, what are your thoughts?
> 
> Hans
> 
> David Dabbs wrote:
> 
> >This is different from the mount issue, which was fixed by the new code
> >drop. This was built with 8k stacks.
> >
> >David
> >

Hardware was my initial thought, perhaps something related to USB and
switching the KVM. Of course, operator error and/or software are usually the
culprit, so I spent a good bit of time last night rerunning that mongo
config under a number of scenarios, none of which reproduced the errors. 

I'm not a hardware guy, so here's a sample of the messages when switching
the kvm between linux and the other machine.



linux kernel: usb 1-2: USB disconnect, address 8
linux /etc/hotplug/usb.agent[10578]: need a device for this command
linux kernel: usb 1-2: new full speed USB device using address 11
linux kernel: hub 1-2:1.0: USB hub found
linux kernel: hub 1-2:1.0: 5 ports detected
linux kernel: usb 1-2.5: new full speed USB device using address 12
linux kernel: drivers/usb/input/hid-core.c: ctrl urb status -32 received
linux kernel: input: USB HID v1.00 Keyboard [FTDI  PS/2 Keyboard And Mouse
I/F] on usb-0000:00:07.2-2.5
linux kernel: drivers/usb/input/hid-core.c: ctrl urb status -32 received
linux kernel: drivers/usb/input/hid-core.c: ctrl urb status -32 received
linux kernel: input: USB HID v1.00 Mouse [FTDI  PS/2 Keyboard And Mouse I/F]
on usb-0000:00:07.2-2.5
linux /etc/hotplug/usb.agent[10613]: need a device for this command
linux /etc/hotplug/usb.agent[10616]: need a device for this command
linux /etc/hotplug/usb.agent[10611]: need a device for this command
linux kernel: usb 1-2: USB disconnect, address 11
linux kernel: usb 1-2.5: USB disconnect, address 12
linux /etc/hotplug/usb.agent[11210]: need a device for this command
linux /etc/hotplug/usb.agent[11220]: need a device for this command
linux /etc/hotplug/usb.agent[11206]: need a device for this command
linux kernel: usb 1-2: new full speed USB device using address 13
linux kernel: hub 1-2:1.0: USB hub found
linux kernel: hub 1-2:1.0: 5 ports detected
linux /etc/hotplug/usb.agent[11384]: need a device for this command
linux kernel: usb 1-2.5: new full speed USB device using address 14
linux kernel: drivers/usb/input/hid-core.c: ctrl urb status -32 received
linux kernel: drivers/usb/input/hid-core.c: ctrl urb status -71 received
linux kernel: input: USB HID v1.00 Keyboard [FTDI  PS/2 Keyboard And Mouse
I/F] on usb-0000:00:07.2-2.5
linux kernel: usbhid: probe of 1-2.5:1.1 failed with error -5
linux /etc/hotplug/usb.agent[11432]: need a device for this command
linux /etc/hotplug/usb.agent[11421]: need a device for this command
linux kernel: usb 1-2: USB disconnect, address 13
linux kernel: usb 1-2.5: USB disconnect, address 14
linux /etc/hotplug/usb.agent[11731]: need a device for this command
linux /etc/hotplug/usb.agent[11733]: need a device for this command
linux /etc/hotplug/usb.agent[11730]: need a device for this command
linux kernel: usb 1-2: new full speed USB device using address 15
linux kernel: usb 1-2: device not accepting address 15, error -71
linux kernel: usb 1-2: new full speed USB device using address 16
linux kernel: hub 1-2:1.0: USB hub found
linux kernel: hub 1-2:1.0: 5 ports detected
linux /etc/hotplug/usb.agent[11854]: need a device for this command
linux kernel: usb 1-2.5: new full speed USB device using address 17
linux kernel: usb 1-2.5: device descriptor read/8, error -71
linux kernel: usb 1-2.5: new full speed USB device using address 18
linux kernel: usb 1-2.5: device descriptor read/8, error -71


In addition, here is a sample of /var/log/messages from a start-up. If vs
suspects hardware, perhaps something will stick out in here:

syslogd 1.4.1: restart.
 kernel: klogd 1.4.1, log source = /proc/kmsg started.
 kernel: Inspecting /boot/System.map-2.6.8-rc2-mm1
 kernel: Loaded 36084 symbols from /boot/System.map-2.6.8-rc2-mm1.
 kernel: Symbols match kernel version 2.6.8.
 kernel: No module symbols loaded - kernel modules not enabled.

...
This seems strange. I definitely have kernel modules configured in:

# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

...

 kernel: usbcore: registered new driver usbfs
 kernel: usbcore: registered new driver hub
 kernel: PCI: Found IRQ 11 for device 0000:00:11.0
 kernel: PCI: Sharing IRQ 11 with 0000:00:07.2
 kernel: 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
 kernel: 0000:00:11.0: 3Com PCI 3c905 Boomerang 100baseTx at 0xdc80. Vers
LK1.1.19
 kernel:  ***INVALID CHECKSUM 003e*** eth0: Dropping NETIF_F_SG since no
checksum feature.
 kernel: NET: Registered protocol family 17
 kernel: Linux agpgart interface v0.100 (c) Dave Jones
 kernel: agpgart: Detected an Intel 440LX Chipset.
 kernel: agpgart: Maximum main memory to use for agp memory: 263M
 kernel: agpgart: AGP aperture is 64M @ 0xf4000000
 kernel: USB Universal Host Controller Interface driver v2.2
 kernel: PCI: Found IRQ 11 for device 0000:00:07.2
 kernel: PCI: Sharing IRQ 11 with 0000:00:11.0
 kernel: uhci_hcd 0000:00:07.2: Intel Corp. 82371AB/EB/MB PIIX4 USB
 kernel: uhci_hcd 0000:00:07.2: irq 11, io base 0000dce0
 kernel: uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number
1
 kernel: hub 1-0:1.0: USB hub found
 kernel: hub 1-0:1.0: 2 ports detected
 kernel: usb 1-2: new full speed USB device using address 2
 kernel: hub 1-2:1.0: USB hub found
 kernel: hub 1-2:1.0: 5 ports detected
 kernel: usb 1-2.5: new full speed USB device using address 3
 kernel: usbcore: registered new driver hiddev
 kernel: drivers/usb/input/hid-core.c: ctrl urb status -32 received
 kernel: input: USB HID v1.00 Keyboard [FTDI  PS/2 Keyboard And Mouse I/F]
on usb-0000:00:07.2-2.5
 kernel: usbhid: probe of 1-2.5:1.1 failed with error -5
 kernel: usbcore: registered new driver usbhid
 kernel: drivers/usb/input/hid-core.c: v2.0:USB HID core driver
 kernel: NET: Registered protocol family 10
 kernel: Disabled Privacy Extensions on device c04519e0(lo)
 kernel: IPv6 over IPv4 tunneling driver
 kernel: Disabled Privacy Extensions on device d2293000(sit0)
 sshd[2626]: Server listening on :: port 22.
 kernel: pnp: Device 00:01.00 activated.
 kernel: pnp: Device 00:01.02 activated.
 kernel: pnp: Device 00:01.03 activated.
 kernel: speedstep_centrino: Unknown symbol
acpi_processor_unregister_performance
 kernel: speedstep_centrino: Unknown symbol
acpi_processor_register_performance
 kernel: powernow_k8: Unknown symbol acpi_processor_unregister_performance
 kernel: powernow_k8: Unknown symbol acpi_processor_register_performance
 kernel: powernow_k7: Unknown symbol acpi_processor_unregister_performance
 kernel: powernow_k7: Unknown symbol acpi_processor_register_performance
 rcpowersaved: CPU frequency scaling is not supported by your processor.
 rcpowersaved: enter 'POWERSAVE_CPUFREQD_MODULE=off' in
/etc/sysconfig/powersave/common to avoid this warning.
 [powersaved][2905]: resmgr: server response code 200
 kernel: hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
 kernel: hda: drive_cmd: error=0x04 { DriveStatusError }
 kernel: ide: failed opcode was: 0xef
 [powersave_proxy][2907]: WARNING: hdparm returned error 5
 kernel: hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error
}
 kernel: hda: task_no_data_intr: error=0x04 { DriveStatusError }
 kernel: ide: failed opcode was: 0xef
 [powersave_proxy][2907]: WARNING: hdparm returned error 5
 ifup: No configuration found for sit0
 kernel: hdb: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
 kernel: hdb: drive_cmd: error=0x04 { DriveStatusError }
 kernel: ide: failed opcode was: 0xef
 kernel: eth0: no IPv6 routers present
 kernel: parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
 kernel: parport0: irq 7 detected
 kernel: lp0: using parport0 (polling).
 kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for
Generic
 kernel: usbcore: registered new driver usbserial_generic
 kernel: usbcore: registered new driver usbserial
 kernel: drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
 kernel: drivers/usb/input/hid-core.c: ctrl urb status -71 received
 xinetd[8560]: Reading included configuration file: /etc/xinetd.d/chargen
[file=/etc/xinetd.conf] [line=26]
 xinetd[8560]: Reading included configuration file:
/etc/xinetd.d/chargen-udp [file=/etc/xinetd.d/chargen-udp] [line

 xinetd[8560]: Reading included configuration file: /etc/xinetd.d/cups-lpd
[file=/etc/xinetd.d/cups-lpd] [line=14]
 xinetd[8560]: Reading included configuration file: /etc/xinetd.d/daytime
[file=/etc/xinetd.d/daytime] [line=11]
 xinetd[8560]: Reading included configuration file:
/etc/xinetd.d/daytime-udp [file=/etc/xinetd.d/daytime-udp] [line

 xinetd[8560]: Reading included configuration file: /etc/xinetd.d/echo
[file=/etc/xinetd.d/echo] [line=14]
 xinetd[8560]: Reading included configuration file: /etc/xinetd.d/echo-udp
[file=/etc/xinetd.d/echo-udp] [line=13]
 xinetd[8560]: Reading included configuration file: /etc/xinetd.d/netstat
[file=/etc/xinetd.d/netstat] [line=14]
 xinetd[8560]: Reading included configuration file: /etc/xinetd.d/rsync
[file=/etc/xinetd.d/rsync] [line=16]
 xinetd[8560]: Reading included configuration file: /etc/xinetd.d/servers
[file=/etc/xinetd.d/servers] [line=12]
 xinetd[8560]: Reading included configuration file: /etc/xinetd.d/services
[file=/etc/xinetd.d/services] [line=13]
 xinetd[8560]: Reading included configuration file: /etc/xinetd.d/swat
[file=/etc/xinetd.d/swat] [line=13]
 xinetd[8560]: Reading included configuration file: /etc/xinetd.d/systat
[file=/etc/xinetd.d/systat] [line=11]
 xinetd[8560]: Reading included configuration file: /etc/xinetd.d/time
[file=/etc/xinetd.d/time] [line=17]
 xinetd[8560]: Reading included configuration file: /etc/xinetd.d/time-udp
[file=/etc/xinetd.d/time-udp] [line=14]
 xinetd[8560]: Reading included configuration file: /etc/xinetd.d/vnc
[file=/etc/xinetd.d/vnc] [line=14]
 /usr/sbin/cron[8609]: (CRON) STARTUP (fork ok)
 xinetd[8560]: removing chargen
 xinetd[8560]: removing chargen
 xinetd[8560]: removing printer
 xinetd[8560]: removing daytime
 xinetd[8560]: removing daytime
 xinetd[8560]: removing echo
 xinetd[8560]: removing echo
 xinetd[8560]: removing netstat
 xinetd[8560]: removing rsync
 xinetd[8560]: removing servers
 xinetd[8560]: removing services
 xinetd[8560]: removing systat
 xinetd[8560]: removing time
 xinetd[8560]: removing vnc1
 xinetd[8560]: removing vnc2
 xinetd[8560]: removing vnc3
 xinetd[8560]: removing vnchttpd1
 xinetd[8560]: removing vnchttpd2
 xinetd[8560]: removing vnchttpd3
 xinetd[8560]: xinetd Version 2.3.13 started with libwrap loadavg options
compiled in.
 xinetd[8560]: Started working: 1 available service
 kernel: Non-volatile memory driver v1.2
 kernel: end_request: I/O error, dev fd0, sector 0
 kernel: end_request: I/O error, dev fd0, sector 0
 kernel: SCSI subsystem initialized
 kernel: st: Version 20040403, fixed bufsize 32768, s/g segs 256
 kernel: BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
 kernel: usb 1-2: USB disconnect, address 2
 kernel: usb 1-2.5: USB disconnect, address 3
 /etc/hotplug/usb.agent[8706]: need a device for this command
 /etc/hotplug/usb.agent[8695]: need a device for this command
 /etc/hotplug/usb.agent[8696]: need a device for this command
 kernel: mtrr: 0xfd000000,0x400000 overlaps existing 0xfd000000,0x200000
 kernel: mtrr: 0xfd000000,0x400000 overlaps existing 0xfd000000,0x200000


David

RE: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[David Dabbs]

> >
> For us to reproduce, we need to have a script of some sort that exactly
> reproduces what you did.
> 
> It is especially significant to note such things as whether you might
> have run out of disk space, etc.
> 

No, that was not the case. Because of that very issue, I just bought a
larger drive so I could complete more extensive mongo runs. I would have
known if the disk had filled. Last time I checked df during the later stages
of a run it was reporting something like 12% in use.

> It makes a lot of sense that you did not run stock mongo, because elena
> runs that a lot and we likely would have hit the bug already if you had.

Yes, except that I reran mongo without the MKFILES and MKDIRS phases, and as
I mentioned in another post, with the exception for an extra print statement
to track script progress, no changes were made to stock mongo sources.

If you believe it will help, I'll tar up my mongo directory and place on my
web site. Will follow-up.


David

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[mjt]

On Wed, Aug 04, 2004 at 04:51:34PM +0400, Vladimir V. Saveliev wrote:
>>If it is due to 4k stacks,
>No, I do not think it is.

>reiser4 now refuses to compile if 4k stack is on.

WTF, Redeeman at least runs Reiser4 with 4k stacks...

What's this about?

-- 
mjt

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[Hans Reiser]

Markus Törnqvist wrote:

>On Wed, Aug 04, 2004 at 04:51:34PM +0400, Vladimir V. Saveliev wrote:
>  
>
>>>If it is due to 4k stacks,
>>>      
>>>
>>No, I do not think it is.
>>    
>>
>
>  
>
>>reiser4 now refuses to compile if 4k stack is on.
>>    
>>
>
>WTF, Redeeman at least runs Reiser4 with 4k stacks...
>
>What's this about?
>
>  
>
V4 likes stack.  If someone can convince me that kmalloc is as efficient 
as stack, I'd like to hear it, because I know I lack expertise on the topic.

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[Christophe Saout]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

Am Mittwoch, den 04.08.2004, 14:47 -0700 schrieb Hans Reiser:

> V4 likes stack.  If someone can convince me that kmalloc is as efficient 
> as stack, I'd like to hear it, because I know I lack expertise on the topic.

The disassembled fast path of kmalloc (with a size of the object known
at compile time) fits on one page. Most of the time it will just return
a pointer from a pool of cached and cache-hot objects.


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[Hans Reiser]

Christophe Saout wrote:

>Am Mittwoch, den 04.08.2004, 14:47 -0700 schrieb Hans Reiser:
>
>  
>
>>V4 likes stack.  If someone can convince me that kmalloc is as efficient 
>>as stack, I'd like to hear it, because I know I lack expertise on the topic.
>>    
>>
>
>The disassembled fast path of kmalloc (with a size of the object known
>at compile time) fits on one page. Most of the time it will just return
>a pointer from a pool of cached and cache-hot objects.
>
>  
>
whereas using stack is 0 instructions or?

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[Christophe Saout]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

Am Mittwoch, den 04.08.2004, 16:57 -0700 schrieb Hans Reiser:

> >>V4 likes stack.  If someone can convince me that kmalloc is as efficient 
> >>as stack, I'd like to hear it, because I know I lack expertise on the topic.
> >>    
> >>
> >
> >The disassembled fast path of kmalloc (with a size of the object known
> >at compile time) fits on one page. Most of the time it will just return
> >a pointer from a pool of cached and cache-hot objects.
> >
> whereas using stack is 0 instructions or?

More or less. But who's counting? ;-)


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[Lamont R. Peterson]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

On Wed, 2004-08-04 at 18:06, Christophe Saout wrote:
> Am Mittwoch, den 04.08.2004, 16:57 -0700 schrieb Hans Reiser:
> 
> > >>V4 likes stack.  If someone can convince me that kmalloc is as efficient 
> > >>as stack, I'd like to hear it, because I know I lack expertise on the topic.
> > >>    
> > >>
> > >
> > >The disassembled fast path of kmalloc (with a size of the object known
> > >at compile time) fits on one page. Most of the time it will just return
> > >a pointer from a pool of cached and cache-hot objects.
> > >
> > whereas using stack is 0 instructions or?
> 
> More or less. But who's counting? ;-)

I do not think it likely to be less, eh? ;-)
-- 
Lamont R. Peterson <lamont@gurulabs.com>
Senior Instructor
Guru Labs, L.C. http://www.GuruLabs.com/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[Hans Reiser]

Christophe Saout wrote:

>Am Mittwoch, den 04.08.2004, 16:57 -0700 schrieb Hans Reiser:
>
>  
>
>>>>V4 likes stack.  If someone can convince me that kmalloc is as efficient 
>>>>as stack, I'd like to hear it, because I know I lack expertise on the topic.
>>>>   
>>>>
>>>>        
>>>>
>>>The disassembled fast path of kmalloc (with a size of the object known
>>>at compile time) fits on one page. Most of the time it will just return
>>>a pointer from a pool of cached and cache-hot objects.
>>>
>>>      
>>>
>>whereas using stack is 0 instructions or?
>>    
>>
>
>More or less. But who's counting? ;-)
>
>  
>
0 is less than a page, by a lot, if done a lot, and we do.

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[Carl-Daniel Hailfinger]

Hans Reiser schrieb:
> Christophe Saout wrote:
> 
>> Am Mittwoch, den 04.08.2004, 16:57 -0700 schrieb Hans Reiser:
>>
>>  
>>>>> V4 likes stack.  If someone can convince me that kmalloc is as
>>>>> efficient as stack, I'd like to hear it, because I know I lack
>>>>> expertise on the topic.
>>>>
>>>> The disassembled fast path of kmalloc (with a size of the object known
>>>> at compile time) fits on one page. Most of the time it will just return
>>>> a pointer from a pool of cached and cache-hot objects.
>>>
>>> whereas using stack is 0 instructions or?
>>
>> More or less. But who's counting? ;-)
>
> 0 is less than a page, by a lot, if done a lot, and we do.

Yes, but... (there's always a but) certain hardware drivers also use a lot
of stack. If you manage to get another (hardware) interrupt in a reiser4
path with >4k stack already used, it's very likely your machine will
explode even without 4k stacks.
And before you ask, some of these problems may be triggered intentionally.
IMHO no user should be able to trigger a kernel crash (maybe except when
writing to kernel memory).
Besides that, some time ago a discussion on linux-kernel about available
stack size without the 4KSTACKS option had very interesting results
(that's where the information in the above paragraphs came from).

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: mongo_copy: cp: cannot stat `/mnt/testfs/testdir0-0-0/f92': Input/output error

[Chris Mason]

On Wed, 2004-08-04 at 17:47, Hans Reiser wrote:
> Markus Törnqvist wrote:
> 
> >On Wed, Aug 04, 2004 at 04:51:34PM +0400, Vladimir V. Saveliev wrote:
> >  
> >
> >>>If it is due to 4k stacks,
> >>>      
> >>>
> >>No, I do not think it is.
> >>    
> >>
> >
> >  
> >
> >>reiser4 now refuses to compile if 4k stack is on.
> >>    
> >>
> >
> >WTF, Redeeman at least runs Reiser4 with 4k stacks...
> >
> >What's this about?
> >
> >  
> >
> V4 likes stack.  If someone can convince me that kmalloc is as efficient 
> as stack, I'd like to hear it, because I know I lack expertise on the topic.

The FS lives in a universe where it shares the computer with other
components.  Using kmalloc allows it to share better, improving the
performance of the system as a whole instead of hogging resources,
especially low memory resources on 32 bit systems.

So, it's likely the switch to kmalloc would increase your overall cpu
usage (very) slightly, and unlikely this switch will be detectable on io
bound workloads.  If it is detectable, then it's a reason to fix
kmalloc, not a reason to avoid it ;-)

-chris