On Mon, Apr 04, 2005 at 01:23:15PM -0500, Steve Lord <lord@xxxxxxx> wrote:
> Marc Lehmann wrote:
> >Is this somewthing inside xfs or is this just setting the st_blksize stat
> >data field? If the latter, then its unlikely to help, as I configured
> >mythtv to use fairly large write's already (minimum 512KB, usually around
> >2MB). But thanks for the tip, it might help some other XFS filesystems I
> >have (although it isn't a problem there).
> This is inside XFS and is different than doing a large I/O. What is
[very detailed explanations skipped]
Thanks a lot for explaining it in that detail!
I'll try chris's patch and see how that improves things.
> The realtime allocator uses a different binary chop algorithm which while
> wasteful, makes it very hard to fragment realtime files. Hmm, buffered works
Hmm, is the realtime code ready for use then? I was under the (likely
wrong) impression that the realtime code is not yet ready.
However, I *guess* I could easily live with, say, 128MB (or even
1GB) realtime extents and live with the internal frgamentation that
will occur: If my interpretation is right (not likely) the realtime
allocator more-or-less treats these realtime extents as the basic unit of
allocation, so internal fragmentation will be extremely high, but external
fragmentation is low?
> on realtime, maybe you could try hacking mythtv to set the realtime flag in
> inodes and see what happens.
> make it more likely for there to be unused space just beyond the last
> extent allocated for a file. Implementing that would take some time by
> someone experienced inside the allocator (Glen are you reading this ;-)
> at the end of the day, there may actually not be much of a payoff.
Quite possible. I think both suggestions might work out.
The choice of a
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ pcg@xxxxxxxx
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE