Marc Lehmann wrote:
I was contacted in private to offer more information, and thoguht it might be
a good idea to let the list know:
* all files are being written into the same directory. like 2-4 slow "dd
of=/xfs/video.dat"'s
Hi Marc,
Do you know if the app is using buffered or direct I/O ? This is
important when it comes to what is doing the actual allocations.
If it really is dd then it is obviously buffered. Also, is there
an O_SYNC on the writes?
How much memory do you have in the box, and what kernel are you
running. I just tried two streams of dd using 1M byte writes of 2G
files - on my laptop with 512M of memory and a single partition
which has my whole system on it, so the layout is non optimal.
One file got 49 extents, the other got 25. Combined throughput was
25 M/sec which is not too bad for my laptop. Just running one stream
on its own ended up with 13 extents - which shows the state of the
free space on my disk. If I switch to O_SYNC for writes it all goes
to pot very quickly, the files checkerboard with each other, but
the extents do come out in order.
It may be the fact that your data is actually coming in slower than
this that is causing part of the problem. If the streams are getting
synced out before they have a chance to build a large chunk of in
memory data that might do it.
If you have enough control, try making each incoming stream live in
its own directory, that will make the allocator start them off in
different allocation groups by default.
Are you replaying or transcoding from the same streams as are being
recorded or from different ones?
The reverse ordering you notice is a little odd, it is definitely
supposed to prefer going the other way.
Steve
|