[lustre-discuss] OST partition sizes

[Scott Nolin]

Ok I looked up my notes.

I'm not really sure what you mean by record size. I assumed when I do a 
file per process the block size = file size. And that's what I see 
dropped on the filesystem.

I did -F -b <size>

With block sizes 1MB, 20MB, 100MB, 200MB, 500MB

2, 4, 8, 16 threads on 1 to 4 clients.

I assumed 2 threads on 1 client looks a lot like a client writing or 
reading 2 files. I didn't bother looking at 1 thread.

Later I just started doing 100MB tests since it's a very common file 
size for us. Plus I didn't see real big difference once size gets bigger 
than that.

Scott


On 4/29/2015 10:24 AM, Alexander I Kulyavtsev wrote:
> What range of record sizes did you use for IOR? This is more important
> than file size.
> 100MB is small, overall data size (# of files) shall be twice as memory.
> I ran series of test for small record size for raidz2 10+2; will re-run
> some tests after upgrading to 0.6.4.1 .
>
> Single file performance differs substantially from file per process.
>
> Alex.
>
> On Apr 29, 2015, at 9:38 AM, Scott Nolin <scott.nolin at ssec.wisc.edu
> <mailto:scott.nolin at ssec.wisc.edu>> wrote:
>
>> I used IOR, singlefile, 100MB files. That's the most important
>> workload for us. I tried several different file sizes, but 100MB
>> seemed a reasonable compromise for what I see the most. We rarely or
>> never do file striping.
>>
>> I remember I did see a difference between 10+2 and 8+2. Especially at
>> smaller numbers of clients and threads, the 8+2 performance numbers
>> were more consistent, made a smoother curve. 10+2 with not a lot of
>> threads the performance was more variable.
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6248 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20150429/78786d3d/attachment.bin>