On Fri, 2006-05-05 at 08:32 +1000, David Chatterton wrote:
> Ming,
>
> What are the I/O characteristics of the application? Typically I
> have seen direct I/O for video data at reasonable sizes, and
> smaller buffered I/O for audio data in media apps. In the
> worse case they mix buffered and direct to the same file. The
> larger the I/O requests the better in terms of reducing
> fragmentation.
I feel that I here want the fragmentation. I will have 10-20 large size
(~10GB) multimedia files write at same time to this RAID0. then later a
background program will dump them to tape. so i want the concurrent
write to be as soon as possible.
so if xfs allocate 0 ~ (16MB-512) to file1, 16MB ~ (32MB-51) file2,...,
then when write to file 1 to file N concurrently. the disk heads have to
move back and forth among these places and thus leave the the poor
performance i saw.
ps, what u mean DDN, the full name is ___?
ming
>
> Some applications take advantage of the preallocation APIs and
> know that they are ingesting X GBs, and preallocate that space.
> This may still be fragmented, but in most circumstnaces the
> fragmentation is far less than without preallocation.
>
> Performance degrading with multiple writers is not unexpected
> if they are jumping around a lot, and there is limited cache
> of the controller etc. That is why for customers with demanding
> media workloads we recommend storage like DDN that have very
> large caches and can absorb lots of streams. But that costs
> a lot more than a jbod!
>
> Coming soon we will introduce to XFS on linux a new mount option
> that will put writers to files in different directories into
> different allocation groups. If you only have one writer per
> directory, then fragementation in those files can be significantly
> better since the writers aren't fighting for space in the same
> region of the filesystem. That will help here but I'm not sure
> it will solve your problem.
>
> Thanks,
>
> David
>
>
> Ming Zhang wrote:
> > Hi, all
> >
> > I have a 8*300GB DISK RAID0 used to hold temporary large size media
> > files. Usually application will write those ~10GB files to it
> > sequentially.
> >
> > Now I found that if I have one file write to it, I can get like
> > ~260MB/s, but if i have 4 concurrent file write, i can only get
> > aggregated 192MB/s, with 16 concurrent writes, the aggregated throughput
> > becomes ~100MB/s.
> >
> > Anybody know why I got such a bad write performance? I guess it is
> > because of seek back and forth.
> >
> > This shows that spaces are still allocated to file with large chunks.
> > thus lead to the seek when writing different files. but why xfs can not
> > allocate space better?
> >
> > [root@dualxeon bonnie++-1.03a]# xfs_bmap /tmp/t/v8
> > /tmp/t/v8:
> > 0: [0..49279]: 336480..385759
> > 1: [49280..192127]: 39321664..39464511
> > 2: [192128..229887]: 39485504..39523263
> > 3: [229888..267391]: 39571904..39609407
> > 4: [267392..590207]: 52509888..52832703
> > 5: [590208..620671]: 52847168..52877631
> > 6: [620672..663807]: 91995584..92038719
> > 7: [663808..677503]: 92098112..92111807
> > 8: [677504..691327]: 92130624..92144447
> >
> > Ming
> >
> >
>
|