Thanks Andreas, clearly the 3-OST configuration will work better (we see that three distinct processes are able to use all the power of all RAID controllers), but we wanted to avoid striping at the file system level inside one OSS. This is why: what we are aiming at is a single mount point file system composed of one or more first level subdirectories each of which is based on one standalone OSS
capable to deliver around 1GB/sec of peak performance. This configuration has an obvious "affinity" advantage of only partial damage in case of loss of one of the OSS machines (only one of the first level subdirectories will become unavailable). I hence thought that enabling the filesystem default stripe count to 3 will then be applied to the mother (0-level) directory, and then there will be the cases when one file could be spread over two or three OSS. And this is exactly the case we wish to avoid. To conclude, is it possible to configure a Lustre file system spread over multiple OSS machines each of which contains 3 OSTs with striping, and still ensure (at the subdirectory level) that any file will always be ending up in one and only one OSS box and will always be striped over 3 OSTs availabe internally inside this given OSS? Thanks ahead again for claryfing this - Andrei. On 4/13/07, Andreas Dilger <[EMAIL PROTECTED]> wrote:
On Apr 13, 2007 12:00 +0200, Andrei Maslennikov wrote: .... > for large streaming I/O for a single file at the client level, *without* > striping. You should try with 3 OSTs on the box, and set the filesystem default stripe count to 3 and see if the mutli-threading on the client can work better than that in LVM. You will get 3x as many requests in flight, 3x as much write cache space in Lustre.
_______________________________________________ Lustre-discuss mailing list [EMAIL PROTECTED] https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
