Re: Was able to reproduce "cp: cannot stat file.x: Input/output error"

[Hans Reiser <reiser@namesys.com>]

David Dabbs wrote:

>  
>
>>>>Hans:
>>>>yes, it [hashing] is only a good idea for filenames larger than 15
>>>>characters.
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>Actually, larger than 7 + 8 + 8 characters, if LARGE_KEY is used.
>>>
>>>      
>>>
>>Oh.  Ok.  LARGE_KEY is the only thing that should be used.
>>
>>    
>>
>>>>it is extremely unrealistic to create the files in one phase and write
>>>>to them in the next phase.  the filesystem will behave completely
>>>>differently.
>>>>
>>>>        
>>>>
>>>Of course. The extra files I added are created once, and should never be
>>>touched again since mongo only operates on the objects it creates. I am
>>>simply loading the test filesystem with a reasonable facsimile of a
>>>      
>>>
>>'normal' Linux file set (with the exception that the files are all zero
>>length).
>>    
>>
>>a huge exception.  I don't grok what you are trying to do here.
>>
>>    
>>
>
>Mongo starts with a clean slate filesystem. I was attempting to run the
>tests on top of something other than a clean filesystem, because that is an
>exceptional situation. Based on your reaction, it is obviously not
>detrimental to measuring relative performance measures. I didn't really care
>about the performance of the MKFILES & MKDIRS phases themselves - that was
>irrelevant. I simply wanted to run the tests on a filesystem that looked as
>much as possible as what one might start with under 'normal' conditions. The
>only reason the files were zero length - and not a copy of real files - was
>that at the time I had limited disk space with which to test. 
>
>But enough of extensions and experiments. I am in no way trying to press a
>case for my MKDIRS/FILES experiments. I do, however, believe mongo should be
>run with file names longer than six characters 
>
ok.

>and that have extensions.
>  
>
this should be without effect, provided that the file creation order is 
the same as the hash/fibration order.

>This is not representative of Linux file system usage, nor does it exercise
>reiser features designed to improve performance, e.g. fibration. In
>addition, as you point out, it should probably not benchmark mounting and
>unmounting the filesystem -- unless there was good reason to have done so.
>
>The real issue, for me at least, is finding a method of determining whether
>the errors I saw were due to hardware or software; if it is the latter,
>whether it can be traced to mongo, the filesystem or Linux.
>
>David
>
>
>
>
>  
>