> -----Original Message----- > From: Hans Reiser [mailto:[EMAIL PROTECTED] > 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. > > > >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. > > > >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