lfs setstripe needs to be run before the file is written since striping layout is determined at file creation time.
What you’ll want to do is lfs setstripe -c <stripe_count> <iozone_output_directory> before you run iozone. Then when you run iozone, make sure to write to a new file, as a file that already existed will have the former striping layout. You can use lfs getstripe to verify.
On Thu, Feb 20, 2014 at 4:15 PM, Patrick Farrell <email@example.com> wrote:
Your comment about dd means that at least some part of your file system is set up to stripe across multiple OSTs, but my first guess on hearing this would be that IOZone is working in a space where the default striping is left at 1. It’s the simplest explanation, though that doesn’t mean it’s right. :)Both dd and iozone are writing into the same directory, my current assumption is that since iozone constantly overwrites the same file that it initially created and wrote to in small chunks of data that striping never steps in...
I assume I can finetune that behavior away....
The lfs operation is run before running a command that will output to a file a a sort of 'touch' which tells lustre to write a file in a specific way?
Thanks,Any pointers would be very welcome...lustre is functioning fine and when using dd from multiple machines with a bs=102400 it uses all OSS.(iozone -Ra -g 64G)Hi all,When I run the iozone benchmark on lustre it ends up only using one OSS server, I assume this has something to do with the way it writes but I'm not really sure where to look, at the moment I am just using automated tests...
HPDD-discuss mailing list