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

[Hans Reiser <reiser@namesys.com>]

David Dabbs wrote:

>  
>
>>-----Original Message-----
>>From: Hans Reiser [mailto:reiser@namesys.com]
>>Sent: Sunday, August 08, 2004 1:09 PM
>>To: David Dabbs
>>Cc: 'ReiserFS List'; Nikita Danilov; Alexander Zarochentcev; E. Gryaznova
>>Subject: Re: Was able to reproduce "cp: cannot stat file.x: Input/output
>>error"
>>
>>most filenames are small.  We have an optimization in reiser4 that
>>assumes filenames are less than 15 characters, which most of them are.
>>
>>    
>>
>
>This is true, but most file names are also not six characters or less with
>no extensions. 
>
>  
>
>>Maybe you should use a list of real filenames as well as a list of real
>>directory names.  You can reuse the filenames, so long as they are
>>unique within a directory.
>>
>>    
>>
>
>I'm not sure uniqueness is a requirement, as mongo allows for duplicate
>filenames. I did use real dirs and files. This is what the MKDIRS and
>MKFILES phases do. I generated a list of most of the actual directories and
>files in my / partition. In my config these are created by MKFILES and
>MKDIRS before the 'stock' mongo phases run.
>
>  
>
>>Hmm, it occurs to me that rather than using the 7 character filename
>>prefix in the hash we should use first 4 letters and last 3 letters.
>>
>>Nikita, zam, what do you think?
>>
>>    
>>
>
>Then you wouldn't store directories and filenames in lexicographic order as
>you originally intended.
>  
>
yes, it is only a good idea for filenames larger than 15 characters.

>
>  
>
>>>Since the above code simply opens and closes the file, every file created
>>>      
>>>
>>is zero length, and it creates _many_ zero-length files.
>>    
>>
>>Why would you want that?
>>    
>>
>
>I didn't explicitly _want_ zero length files, I just did the minimum to
>generate the files. I can easily go back and write one byte to the files,
>but that (shouldn't) really have an impact on the operations against the
>files created by reiser_fract_tree and later
>modified/read/overwritten/deleted by later phases because the files created
>by MKFILES are in directories not manipulated by the stock mongo phases.
>They use the files and directories created by reiser_fract_tree. The reason
>I added the dirs and files created by MKDIRS/FILES was to have mongo work
>with a filesystem 'loaded' with as much metadata as a real system might
>have. If this adds nothing to the benchmarking then simply run with
>MKFILES=off and MKDIRS=off.
>  
>
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.

>
>  
>
>>>I made the following changes, see http://dabbs.net/reiser4/mongopl.html
>>>      
>>>
>>for more context.
>>    
>>
>>>In
>>>
>>>init_fsys:
>>>  don't unmount the filesystem after mkfs * df.
>>>
>>>mongo_launcher:
>>>  don't call &mount_fsys; at beginning and &umount_fsys; at end of each
>>>phase
>>>
>>>
>>>Only umount_fsys at end of function mongo.
>>>
>>>
>>>David
>>>
>>>
>>>      
>>>
>>ok.  Unmounting between phases was probably a bad idea, as it benchmarks
>>unmounting.  It should be fixed.
>>    
>>
>
>Mounting/umounting between phases shouldn't cause errors, but I focused
>there because the errors I saw didn't begin until the copy phase, which is
>the first phase where mongo _reads_ what was created. Perhaps something is
>not being committed, at least with my hardware/config, despite the fact that
>there's a sync at the end of every phase iteration. I also added a sync
>command before the final umount.
>
>David
>
>
>
>
>
>  
>