I don't really fancy this suggestion that much - you are proposing an
apples - to - apples for 1/2 the performance. With proper LVM
configuration we could get full performance.
Yes, that exposes one to more HBA/DDN vulnerabilities, but not more than
a higher stripe_count would do. I think this is the way to get full BW
on wide striping shared files.
- Peter -
Andreas Dilger wrote:
On Nov 23, 2006 22:39 -0700, Lee Ward wrote:
On Thu, 2006-11-23 at 15:03 -0700, Andreas Dilger wrote:
For an apples-apples comparison, it would be possible to deactivate 160 OSTs
(one per OSS) on MDS via "for N in ... ;do lctl --device N deactivate;done"
and then run the SSF and FPP jobs again. This will limit the FPP jobs to
160 OSTs (like the SSF). It might also be useful to disable 161 OSTs (leave
159 active) to avoid the aliasing in the SSF case, or alternately have
clients each write 7MB chunk sizes or something.
For our formal testing, we have in our scripts a section that precreates
files, locating them on specific OSTs. Would that be a suitable
alternative to this reconfiguration of lustre you suggest? What you
suggest is possible, of course. I would just rather not deviate our
process without a good reason.
Sure, precreating files on, say, the first 160 OSTs in a round-robin manner
for all of the client processes for FPP, and similarly forcing the one SSF
file to be created starting on ost_idx 0 will use the same 160 OSTs.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
_______________________________________________
Lustre-devel mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-devel