Re: Max obtainable performance for a single OST

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 <adilger-KYPl3Ael/zSakBO8gow8eQ@xxxxxxxxxxxxxxxx> 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
Lustre-discuss-KYPl3Ael/zSakBO8gow8eQ@xxxxxxxxxxxxxxxx
https://mail.clusterfs.com/mailman/listinfo/lustre-discuss